Re: [Nautilus-list] Optimizations

[Michael Meeks <michael ximian com>]

Hi Alex,

On Mon, 2002-03-11 at 03:14, Alex Larsson wrote:
> With this and some patches to other modules the top of the profile when 
> loading several large directories is:
> 
> 00080040 194      0.981483    __malloc                /lib/i686/libc-2.2.4.so 
...
> Seems hard to improve this by doing nautilus changes.

	What does that mean ? ;-) clearly all these methods are called by
nautilus ? surely we can still go around removing:

	for (i = 0; i < 100000; i++) {
		g_free (g_strdup ("Time wasting"));
	}

	:-) surely the important thing is to find who is doing all the hash
table lookups, and where all the memory allocation is coming from ? are
you using gprof ? it'd be interesting to post the trace somewhere for
everyone to see - if that's possible ?

	One thing that I think might result in pleasant speedups is getting
various modules to use the libXML SAX parser instead of parsing the
whole document, dupping it and then freeing the original. If you do an
strace -ttt -f nautilus you can see how much time gconf spends not just
starting up, but then parsing new files when new 'directories' are hit.
The same is also true of bonobo-activation.

	Indeed, with bonobo-activation I'd also like to reduce the amount of
traffic / dupping of huge query results [ also noticable on a profile ]
- by shipping our locale off to the server at client registration time [
you'll notice there is a parameter in addClient for doing just that ].
Thus the server would not only respond faster to queries, use less
blocking & context switching to get the vast [1] results back, but also
we'd significantly reduce the in-core, active dataset size of
bonobo-activation which is currently ~1Mb.

	Oh, and finally my mental list of optimizations has 'multiple icon list
redraws' at quite a high point. The multiple re-drawing ( and presumably
re-layout ) of the icon view as we switch directories is quite obvious
with the naked eye, and is quite possibly a performance issue. It would
be good to trace back some size allocation details on that widget.

	What do you think ? it'd be great to know if you're interested in
working on any of the above...

	Regards,

		Michael.

[1] - export ORBIT2_DEBUG=traces if you don't believe, the oaf query
results are vast, and most of it translation strings for languages we're
not interested in.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot