GNOME Bugzilla – Bug 362139
nautilus takes very long to display a directory with many files
Last modified: 2012-09-19 03:52:10 UTC
Please describe the problem: When I navigate to /usr/share (containing 326 objects) and switch to list view, nautilus is blocked for about 25 seconds. During this time the CPU goes up to 100% and nautilus cannot be used anymore. This gets much worse when the directory contains even more files. E.g. when I go to /usr/lib (containing > 1800 objects) nautilus hangs for several minutes. All this does not happen in icon view. Steps to reproduce: 1. Open nautilus 2. Go to /usr/lib 3. Switch to list view Actual results: Nautilus hangs for several minutes and eats up 100% CPU. Expected results: Nautilus opens the directory within a few seconds. Does this happen every time? Yes. Other information: I created a sysprof profile, which I will attach.
Created attachment 74682 [details] sysprof profile for nautilus opening /usr/share
The 'perf' keyword[1] could be added. [1] As said on http://bugzilla.gnome.org/describekeywords.cgi
By the way, this bug does not occur with nautilus 2.14.3 (Debian Etch) but with nautilus 2.16.1 (Ubuntu Edgy) it does.
I've seen bug 320282 and although the summary there is not clear it seems this is duplicate of it...
Nelson: I don't think this is a duplicate of bug #320282. #320282 was filed before release of Gnome 2.14, but the performance problem noticed by me occurs on Gnome 2.16 and can't be reproduced on 2.14. So it seems to be a bug introduced with 2.16.
might be a duplicate of bug #356836
Ubuntu bug about that: https://launchpad.net/products/nautilus/+bug/66249 "When I open a large folder (+2000 folders and files, mainly mp3-files) Nautilus hangs for minutes before it shows the contents of the folder. Sometimes Nautilus crashes altogether. It's a vfat partition. When I set Nautilus to "Icon view", it's significantly faster, but still not near as fast as I'd expect it to be. ... > Thanks for your bug. What version of Ubuntu do you use? What view and zoom level do you use? ... I'm on ubuntu-edgy, zoomlevel is 50%, but that doesn't seem to affect speed, after a few tests. It's mainly a problem when it's on "List View". ..."
Being the bug in listview, it could be GtkTreeView fault, or not (haven't seen the profile). If it's GtkTreeView fault then the situation could improved when this two[1] performance bugs are fixed in GtkTreeView. [1] bug 153613 and bug 168654
I can confirm this bug on my laptop. It's very annoying. Laptop Pentium M 1.86 GHz with 5400 rpm hard disc. Ubuntu 6.10 Edgy test directory : /usr/bin (1513 files) For test i just open the /usr/bin directory on double-clicking on it (in detail mode not in icon mode). Konqueror (version 3.5.5) => open time 1 or 2s Dolphin (version 0.6.0) => open time 1 or 2s Thunar (version 0.4.1) => open time 20 (a recent Thunar version is faster) Nautilus (version 2.16.1) => open time 76s You can see that there is a big bug in Nautilus when displaying large directory.
Really very slow!
Check if you have accessibility enabled, for example: $ nautilus -c GTK Accessibility Module initialized Bonobo accessibility support initialized running nautilus_self_check_file_utilities ... With accessibility disabled, /usr/lib opens within few seconds but it's very very slow with accessibility enabled (due to inefficient tree view implementation in gail).
I confirm this bug on v.2.20.0 running Ubuntu Gutsy. Nautilus takes very long to show a list view and quite a second to show the same as icon view.
I had accessibility enabled. Disabling it, nautilus now performs fine.
*** This bug has been marked as a duplicate of bug 356836 ***