Re: [Nautilus-list] Optimizations

[Alex Larsson <alexl redhat com>]

On 11 Mar 2002, Michael Meeks wrote:

> 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"));
> 	}

Sure. If we have a loop like this we can fix it. But in general the policy 
in nautilus for strings is that all getters return a copy of the string. 
This makes for more robust and consistant memory management handling, 
something i think is worth .9% performance. 

This is not to say that if we find some ridicolously wasted string copying 
(like e.g. the nautilus_file_get_display_name() call being called when 
sorting a directory and strdup:ing each time) we can't fix it. But i don't 
want any large scale changes like this.

What I meant by it being hard to fix was that there were no "obvious" 
hotspots. 
 
> 	:-) 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 ?

This was done using oprofile, so I have no call stacks. Only the flat 
profile.
 
> 	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.

Yes. This sounds like a good idea. Especially the places that read largish 
xml files. I don't think it matters for e.g. reading the icon xml files.

> 	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.

Good stuff.
 
> 	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.

Well. This is due to the async/incremental loading that nautilus uses. 
There are various tweaks we do that try to minimize the issues with this 
on local files, such as the initial delay before laying anything out. This 
is a hard problem to solve though, as the asynchronicity is part of the 
core design of Nautilus. I know the Mozilla project had the same sort of 
problems with their incremental reflows, and it took a lot of tweaking to 
get it good.

The best way to handle this is to make local file browsing as fast as 
possible, because if reading a largish directory is instant, multiple 
reflows will not be a problem. And making stuff faster is always good. 
We need to look into the I/O we schedule and make sure we do the minimal 
work that is needed.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a maverick umbrella-wielding rock star who hangs with the wrong crowd. 
She's a blind goth Valkyrie with someone else's memories. They fight crime!