GNOME Bugzilla – Bug 356836
Too slow in showing directories with lot of files.
Last modified: 2015-06-15 23:08:24 UTC
I can't understand why it takes so long. Is it the rendering, and is all the rendering done before showing the first results? Perhaps working with threads might be a good improvement: - get the first 20 files or what will fit - depending on window-size and font-size - to the window. - show the first 20 files and get the next results in an extra thread. Other information: Description of Problem: If you open a directory for the first time in a session, like /usr/bin, nautilus shows a 'please wait' - icon. On my somewhat recent machine, it takes more than 10 s to show the first results. Nautilus doesn't show more information than - i.e. midnight-commander, which responds immediately. I may even hit 'END' to jump to the last entry with mc. Steps to reproduce the problem: 1. Open Nautilus. 2. Go to /usr/bin Actual Results: Needs more than 10 s. to show the (first) files. Expected Results: Show some files immeadiately. How often does this happen? Every time after reboot when a big directory is visited the first time. Additional Information: All gnome 'file (open)'-Dialogs behave the same. This is very annoying if you're asked in firefox, how to open a file (like a PDF). You know it is xpdf but while xpdf is in the path, you have to give the full path (another bad decision). Now you tell the dialog /usr/bin/ and have to wait, and wait, and wait. Although you typed /usr/bin/xpdf you'll have to wait till the File-Dialog found it.
i can absolutely confirm this, nautilus is as slow as it can get, but not only when opening directories the first time, but always. (tested on reiserfs and fat32) 1. in a directory with 2800 files nautilus needs 7 seconds in symbol (icon?) view. (sorry, don't know what it's called in english) to display its content. if you switch to list view nautilus takes 16(!!!) seconds again to show exactly the same files, just with another layout! switching back to symbol view, it takes relaxing 5 seconds again, for something which was displayed a few seconds ago. 2. sorting files by name, date, size, etc. is also quite slow for doing nothing (half a second). 3. changing the sizes of thumbnails is quite slow, too!
(sorry, for double posting) additional information: - Gnome 2.16 - Ubuntu 6.10 - Linux version 2.6.17-8-generic (root@vernadsky) (gcc version 4.1.2 20060906 (prerelease) (Ubuntu 4.1.1-13ubuntu2)) #2 SMP Tue Sep 19 11:58:06 UTC 2006 (Ubuntu 2.6.17-8.22-generic) thx!
Same here, 9 seconds for /usr/bin on Ubuntu 6.10, Nautilus 2.16.1 In addition, opening folders in list view by clicking the triangle in front of them will often show an <Empty> before getting round to displaying the contents. Which wouldn't be a problem if it was fast, but at current speeds it's simply incorrect and should read <Scanning> or something until Nautilus is done with the folder.
I confirm the same here, Ubuntu 7.04 i386 - fresh install (new /home - to be sure) on AMD x2 4200+ slow on first opening /usr/bin slow on dialogs when there's a file to open/save in a crowded folder
nautilus on xfce shows similar behaviour - a problem of the underlying library? http://bugzilla.xfce.org/show_bug.cgi?id=2902
I have the same problem. Anything from 2 - 20 seconds to open a folder with 400 files. Each file is ~500 bytes. The window also goes grey for a few seconds under compiz - indicating that nautilus becomes temporarily unresponsive. /usr/bin took 15 seconds. I'm using Ubuntu 7.10 with Nautilus 2.20.0. If someone can add some information about what happens during this process - maybe we can give some more detailed information.
I've just found that issuing 'killall nautilus' seems to give a breath of life to it. Nautilus behaves very well after doing this.
@ jarlathreidy@gmail.com, #7: I don't think it has to do with "killall". It's just that after a first read the list is in the cache, I guess. Therefore it is fasster on the second run, no matter how you go there.
Adding 'perf' keyword. Also, this topic has recently been brought up in nautilus mailing list, see "Possible speed enhancement" subjects in: http://mail.gnome.org/archives/nautilus-list/2008-September/thread.html http://mail.gnome.org/archives/nautilus-list/2008-October/thread.html
*** Bug 478184 has been marked as a duplicate of this bug. ***
*** Bug 610362 has been marked as a duplicate of this bug. ***
I have a test directory with 8000 files. Displaying this with nautilus require a very big lot of time, the processor run with 100 % CPU load and nautilus is not responsive and after I had wait 10 minutes I killed nautilus. A ls -l dir end after approx. 3 sec. With for example the thunar file manager, the needed time is relativelly long but much better as for nautilus. Konqueror need approx 10 sec. The amount of memory used by nautilus was probally about 15 MB, this is also too much. The nautilus version is 2.28.4
[Bumping version number as per comment 12] Also see bug 343616
Same issue here, with Ubuntu 11.04
Still present in gnome 3.1.91, nautilus takes about 5 minutes to list a 10.000 files dir, while ls -l do it in 3 seconds!
With Nautilus 3.2.1 (default in Ubuntu 11.10) things are better, but it greatly depends on the contents of the folder. For example, it takes 38 seconds to open a folder with 15,000 images (.img and .hdr) but only ~6 seconds if the files are .dcm. This is having the "show thumbnails" from Edit/Preferences/Preview/ disabled.
This has ALWAYS been an issue with nautilus. It's unacceptably slow, even with v3.2.1 it takes a second to show just 60 rar files! In Ubuntu 11.10 opening /usr/bin takes about 10 seconds, for just 1700 items. Its almost 2012 and still nothing has been done about it, are GNOME developers retarded and dont give a damn fuck about the stuff that matters?!
Nautilus 3.5.4 is still very slow when opening folders with many files. Nearly all of gtk+ based file managers have the same sluggish issue such as nautilus,thunar,marlin ,etc. In contrast, dolphin works very well without this bug.
*** Bug 659410 has been marked as a duplicate of this bug. ***
*** Bug 629845 has been marked as a duplicate of this bug. ***
*** Bug 362139 has been marked as a duplicate of this bug. ***
Just to confirm that I'm mostly a happy user of Nautilus :-) ..except for this problem.
In Nautilus 3.4.2 with Ubuntu 12.10 64 bits the main problem seems to be caused by the "Show thumbnails" option. To put a quantitative example. Imagine we open a folder with 7000 dcm files in a modern laptop: -Nautilus with "Show thumbnails" enabled takes 43 seconds -Nautilus with "Show thumbnails" disabled takes 3 seconds As a reference, -GNOME Commander takes 1 second It seems clear what is causing the problem. Maybe adding an option to disable thumbnails when the folder is bigger than X files would solve it?
Please, disregard the previous post. I am sorry for the mistake. I was opening twice the same folder changing the "Show thumbnails" option (instead of 2 different folders changing the thumbnails option). Same situation as before, regardless of the "Show thumbnails" status: -Nautilus (1st time opening the folder) takes 43 seconds -Nautilus (2nd time opening the folder) takes 3 seconds I've tried it with Ubuntu 13.04 Beta1 and the results are about the same. It seems whatever nautilus is doing the first time it opens a folder (but not the second time) is what is causing the delay.
I can confirm Gorka's report. Preview and display options don't affect the delay. After opening up a folder for the first time in a session the delay is smaller on subsequent access but still excruciatingly big compared to Dolphin.
Still in 2014 year, but Status NEW. Are Gnome developers gonna do something with it?
Thanks for taking the time to report this. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 711044 ***