Re: Making nautilus faster with large directories

Federico, you are right.

I didn't notice the problem when I looked at it the first time.  I
deactivated thumbnail generation in nautilus and opened my test folder
with 2200 images in it... it was fast (like ~1 sec) because I forgot I
opened it recently so it had "preloaded" data in memory.  That's why I
thought nautilus was ok with regular files.

I just redid that test for the first time after booting and it took like
8 seconds, reading a lot from the disk and almost 0% of CPU.  The next
time it takes 1 sec, 100% CPU and zero disk reading.

I tried killing nautilus and deleting ~/.thumbnails to repeat the test
but it kept doing it in 1 sec.  I even closed gnome, init 3 my system
then got back to init 5 and still it was doing it in 1 sec.  Only after
rebooting I was able to reproduce the long pause before the files
showing up.

El mi�08-12-2004 a las 21:30 -0600, Federico Mena Quintero escribi� On Sun, 2004-12-05 at 18:41 -0500, William Lovaton wrote:
> > Now that nautilus has received lots of love, may be it's a good time to
> > propose another improvement: Make it faster with directories that have a
> > large number of files in it.  Specially the files that could use
> > thumbnailing like images, video, etc.
> Thumbnailing has its own performance concerns, but...
> What about loading "simple" directories with lots of files?  I've been
> working on speeding up GtkFileChooser, which had timings notoriously
> slow and similar to Nautilus's.  Things I learned:
> - Using a tree model with a GtkTreeModelSort on top, *and* populating
> the tree model incrementally, is a bad idea.  Ideally, your tree model
> should implement GtkTreeSortable on its own.
> - If you really use a GtkTreeModelSort, try to load as much as you can
> of a folder into your tree model, and *then* stick under the
> GtkTreeModelSort.  That way sorting is only done once.

I don't know nothing about this but, is GtkTreeModel* related in some
way to the icon view in nautilus or with nautilus for that matter??
Using list view and icon view doesn't make any difference in the

I'm using FC3 with GTK+ 2.4.13 and eog's file chooser takes like 3
seconds with the same test directory.  So, it doesn't seem that nautilus
is using the same infrastructure.

> - Try to read as much of a folder as possible before any sorting is
> done.  The file chooser used 100 items per notification from the
> gnome-vfs-async functions; now it uses 10000 items, so most folders can
> be read in one pass.
> For GtkFileChooser, this reduced the time to load /dev from 12 seconds
> to around 4.  Still not as good as MC's 0.3 seconds, but it's a big
> improvement anyway.  I wrote about this here:

Neat!  I guess this is in GTK+ 2.4.14 right??

BTW, how many files do you have in /dev??  New distros doesn't have many
files in /dev nowadays.  :-)


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