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.

7 Answers
7

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.

I'm a programmer, though not yet good enough to contribute. Just out of curiosity, how did you do the trace?
–
Coding DistrictAug 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).
–
GillesAug 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

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.

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 DistrictAug 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 KooijAug 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.
–
afrazierFeb 17 '11 at 21:52

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.

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 JenkinsJan 31 '13 at 11:49

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.