Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I'm wondering why Nautilus is very slow when opening a directory containing lots of files. My /usr/lib dir for example has 1900 files and it takes approximately 5+ seconds to show everything. It has been like this since I installed Ubuntu few months ago and it's really quite annoying sometimes. I don't have powerful hardware but I know that Windows Explorer is so much faster than this.

Is there anything that can be done to speed it up?

Ubuntu 10.04

share|improve this question
1  
My guess would be that Nautilus utilizes ls to make its list while Explorer has a cache. –  digitxp Aug 14 '10 at 20:53
    
What kind of system it is? I think this is a big factor. It would be "slow" on my netbook, but not so much on an i7 with with 4+GBs of ram. –  Chris Aug 26 '10 at 18:30
    
Related on Ask Ubuntu: Nautilus is very slow –  slhck Jan 31 '13 at 13:02

7 Answers 7

up vote 26 down vote accepted

Tracing the execution of nautilus shows that the slowness is due to a combination of two factors:

  • It's smart about displaying useful information about each file. It looks inside the contents of files to determine what icon to use, and possibly show a preview. This can be toned down by turning previews off in the preferences.

  • It does a lot of useless work (such as stating each file multiple times, and checking /proc/filesystems even for non-directories). All you can do is learn programming, improve the program and send a patch. Or at least send the authors a feature request (please make it faster).

  • It calls several external processes for each directory, I haven't explored what they do.

share|improve this answer
    
Good answer :D! +1 for patching + featurerequestrequest :D –  BloodPhilia Aug 14 '10 at 21:39
    
I'm a programmer, though not yet good enough to contribute. Just out of curiosity, how did you do the trace? –  Coding District Aug 14 '10 at 21:52
2  
@Derek: strace -f -ttt -p1234 -o nautilus.strace where 1234 is the pid of nautilus. I haven't analyzed the trace in detail, just glanced at the lead up (lots of stuff involving subprocesses) and the per-file stuff (multiple stats, and an open for some files). –  Gilles Aug 14 '10 at 21:57
1  
A lot of the multiple stat()'s come from library calls, many from glibc. –  Tim Post Aug 17 '10 at 11:05

This reminded me of a talk I had with Alexander Larsson, the lead developer for Nautilus and other projects including GVFS.

Giles his answer, specifically the bit about Nautilus looking inside the content of files, touches on the major reason why Nautilus is "slow". However Giles doesn't explain why this is slow, which might be obvious to some, but not to others. Here's what Alex had to say:

Say you start with a blank slate, i.e. you have not accessed the filesystem at all. Now say you run stat(“/some/dir/file”). First the kernel has to find the file, which in technical terms is called the inode. It starts by looking in the filesystem superblock, which stores the inode of the root directory. Then it opens the root directory, finds “some”, opens that, finds “dir”, etc. eventually finding the inode for file.

Then you have to actually read the inode data. After first read this is also cached in RAM. So, a read only has to happen once.

Think of the HD like an old record player, once you’re in the right place with the needle you can keep reading stuff fast as it rotates. However, once you need to move to a different place, called “seeking” you’re doing something very different. You need to physically move the arm, then wait for the platter to spin until the right place is under the needle. This kind of physical motion is inherently slow so seek times for disks are pretty long.

So, when do we seek? It depends on the filesystem layout of course. Filesystems try to store files consecutively as to increase read performance, and they generally also try to store inodes for a single directory near each other but it all depends on things like when the files are written, filesystem fragmentation, etc. So, in the worst case, each stat of a file will cause a seek and then each open of the file will cause a second seek. So, thats why things take such a long time when nothing is cached.

Some filesystems are better than others, defragmentation might help. You can do some things in apps. For instance, GIO sorts the received inodes from readdir() before stating them hoping that the inode number has some sort of relation to disk order (it generally has) thus minimizing random seeks back and forth.

One important thing is to design your data storage and apps to minimize seeking. For instance, this is why Nautilus reading /usr/bin is slow, because the files in there generally have no extension we need to do magic sniffing for each. So, we need to open each file => one seek per file => slooooow. Another example is apps that store information in lots of small files, like gconf used to do, also a bad idea. Anyway, in practice I don’t think there is much you can do except try to hide the latencies.

He ended with the following note:

The real fix for this whole dilemma is to move away from rotating media. I hear the intel SSDs are teh shit. Linus swears by them.

:-)

share|improve this answer
3  
Interesting :) However, if seek is the root cause of the slowness, I'm still wondering why is Windows Explorer so much faster then? Certainly not due to hardware. –  Coding District Aug 17 '10 at 20:13
3  
If I had to guess I would say it doesn't do magic sniffing but simply does file detection based on the extension (I can confirm this for Windows XP). –  Bruce van der Kooij Aug 18 '10 at 5:52
1  
Exactly. Explorer (for the most part) doesn't do any kind of file sniffing, it simply uses the extension. If it needs to render a preview or read an icon, well, then it has to open the file. You can see this if you open a large folder full of .exe files. A shell extension could force Explorer to open a file to do some sniffing too. For example, some archive utilities will examine .exe files to see if they're SFX archives. MS has invested a lot of effort in doing things to try to speed Explorer up, both in actual speed and apparent speed. –  afrazier Feb 17 '11 at 21:52

In the "Preview" tab under "Edit -> Preferences", try switching all the options to "Never".

It also helped me enormously to turn off "Assistive Technologies". You can do this in "System -> Preferences -> Assistive Technologies". Uncheck "Enable assistive technologies".

You'll have to log out and back in for the latter change to take effect.

share|improve this answer
    
This gives me very modest improvements. Deleting bookmarks made a much bigger difference. –  Peter Jenkins Jan 31 '13 at 12:53

Try using an alternative file manager such as Thunar. Thunar is much faster at loading directory listings and more stable for copying files from my NTFS usb hard drive to ext4, though with large sets of files it seems to have trouble like Nautilus.

Here's a link for switch script https://help.ubuntu.com/community/DefaultFileManager

share|improve this answer
    
Great workaround ! I love the "sudo apt-get install thunar" and "exo-preferred-applications" then select Thunar in (Utilities > File Manger) solution. –  Doud Sep 20 '11 at 1:20

If you have xfce installed in a Gnome system and you're never using it, remove exo-utils

It fixed my problem, along with the problem of Chrome not opening files correctly after they download.

share|improve this answer
    
Didn't help for me. exo-utils is also required by lots of packages including the xfdesktop4 package so it's quite hard to remove: sudo dpkg -r --ignore-depends=xfce4-terminal,thunar-volman,squeeze,thunar,xfce4-panel,xfce4-v‌​erve-plugin,xfdesktop4 exo-utils –  Peter Jenkins Jan 31 '13 at 11:49

In the "Preview" tab under "Edit -> Preferences", try switching all the options to "Never".

It also helped me enormously to turn off "Assistive Technologies". You can do this in "System -> Preferences -> Assistive Technologies". Uncheck "Enable assistive technologies".

You'll have to log out and back in for the latter change to take effect.

share|improve this answer
1  
Time to open a large folder reduced from about 30 seconds to maybe two seconds. Good grief. –  wsmart Nov 11 '12 at 17:39
    
My post was deleted here by another user. apparently. Wanted to say thanks to Jay for his post as it made a huge difference for my Nautius slow issue. Be real, be sober. –  wsmart Nov 17 '12 at 18:50

I finally figured out what is making nautilus so slow: bookmarks.

To fix it delete all your bookmarks, restart and then add back the ones you can't live without.

Using strace I realised that nautilus was stating lots of files for every view. Even files that were not in directory I was browsing during the trace. I think nautilus is trying to pre-cache these bookmarks.

I had one network drive as a bookmark ... this might have been the reason why nautilus was taking several seconds to load.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.