Re: [Nautilus-list] Nautilus Performance Analysis

[Darin Adler <darin bentspoon com>]

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

A number of people have volunteered to work on Nautilus recently. I'd like 
to get people signed up to look into these various problems. I'm happy to 
help get the solutions to 100%, but it would be great to have people pick 
some of these and drill down to find exactly what's wrong and the best 
solution.

Let's tackle some of these, as soon as possible.

On Tuesday, August 14, 2001, at 07:09  AM, Alan Cox wrote:

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

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

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

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

> This is followed by the directory scan pattern with some directories being
> checked 15 + times in a via lstat

We should find out why any particular directory was checked more than 2 or 
3 times.

> Loading a jpeg over NFS (ie double clicking it) takes 25 seconds to view
> on my Athlon 550. Loading it off disk takes < 1. Looking at tcpdump traces
> it seems the jpeg reader is asking the OS to read tiny little bits at a 
> time

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

> Also an image load appears to cause another full screen window covering
> the desktop to be generated ???

Strange, and a mystery. I've never seen this.

Guys, let me know which of these you're going to tackle, and I'll try to 
point you in the right direction. With further understanding of why the 
existing code and caches still result in repetitive operations, we can 
decide whether to add caches, or just to fix design, for each of these 
problems.

    -- Darin