Re: [Nautilus-list] Nautilus Performance Analysis

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]