Re: [Nautilus-list] Nautilus Performance Analysis

[Alan Cox <alan lxorguk ukuu org uk>]

> Thanks for the analysis, Alan. I am naturally embarrassed about these 
> fundamental mistakes.

Im sure they are no worse than my UI design mistakes 8)

> > -	Repeated reloads of /usr/share/eel/fonts/urw/n019003l.pfb
> 
> Maybe Ramiro can comment on this. One bit of good news is that Nautilus 
> won't have its own font handling at all if we do the GNOME 2 port well, so 
> this might just go away on its own as we port to GNOME 2.

Ah that would make sense actually - if its Gnome thats doing the font
handling then it may be that someone just needs to bump the refcount on used
fonts. My trace has 4877 opens and loads of that font btw 8) so it looks
like this is going to be a big big win.

> > -	Repeated long stat walks in search of image files, without caching
> > 	the found path when it completes. The icon for a given file isnt
> > 	going to walk, remember the locatiom
> 
> There is an icon cache that should prevent this. But it's possible that we 
> need a lower level icon path cache. It would be easy to have a separate 
> cache of paths that do and don't exist -- perhaps that's all we need.

Looking at the trace I dont think the icon cache is doing all of its job
then. I seem to see multiple loads of the same icon. I will verify that

grep open /tmp/wombat | \
	grep "/usr/share/pixmaps/nautilus/gnome/i-regular.png"| wc -l
     46

Interestingly each .thumbnail is opened twice, consecutively :

14:20:10 open("/home/anarchy/.thumbnails/oslo.aa.jpg.png", O_RDONLY) = 24
14:20:10 open("/home/anarchy/.thumbnails/oslo.aa.jpg.png", O_RDONLY) = 24
14:20:10 open("/home/anarchy/.thumbnails/palmax.aa.jpg.png", O_RDONLY) = 24
14:20:10 open("/home/anarchy/.thumbnails/palmax.aa.jpg.png", O_RDONLY) = 24
14:20:11 open("/home/anarchy/.thumbnails/1.aa.jpg.png", O_RDONLY) = 24
14:20:11 open("/home/anarchy/.thumbnails/1.aa.jpg.png", O_RDONLY) = 24

So some caching seems to be going on but not a vast amount


> > -	During the scan it keeps stating my home directory, .Trash and then
> > 	doing a getuid() and a password/NIS lookup. The fact it isnt
> > 	doing a name/uid cache is killing it over networks. In fact this
> > 	not the NFS handling appears to be a major culprit. Cache uid/name
> > 	entries. NIS or LDAP really work better if you do.
> 
> Can we cache these forever? Or is there some way to tell if a user name is 
> changed while Nautilus is running? I'll put in a cache for this right away,
>   if you can help me understand whether and/or when I would need to 
> invalidate it.

Usernames in Unix normally get reissued after a long time because the uid
owns the rights so reissuing the same uid reissues the same rights to
existing not cleaned up files. apps I've seen being command line like tar
just cache. I guess a 30 minute timeout is going to be fine. It might be
best to ask the sun guys - NIS itself has internal assumptions about
timeouts and they should have the best feel for this.

> > -	Early on the file names are read over a pipe/socket from another
> > 	thread. They are sent one at a time and this causes a mass of task	switches,
> >  enough I can see it on x86, while on other platforms it
> > 	will hurt far more. Shove things down sockets in big chunks, it
> > 	really pays off
> 
> This is a gnome-vfs issue, I think. Anyone interested in tackling it?
> 
> > -	Repeated reparsing of i-regular.xml, several times a second
> 
> Again, the icon cache should prevent this, but perhaps there's some simple 
> reason it doesn't.

Interestingly i-regular.xml is also parsed 46 times. 

> We are reading it with gdk-pixbuf. I imagine this is a bug in the 
> gdk-pixbuf loader architecture. Perhaps the thing to do is to find a way 
> to add a level of caching. The fix to this is probably to change eel's

Or to fix gdk_pixbuf. What else uses gdk_pixbuf to load large jpg images
and I'll do some comparison tests


Looking at the I/O patterns it seems that the code tackling the mini jpeg
and text file stuff is running in parallel to the original directory scan.
That seems odd to me in terms of performance but I have no measurements to
back up the instinct

Alan