Nautilus is very slow when opening folders with many files

Bug #869793 reported by Gorka Navarrete on 2011-10-07
394
This bug affects 87 people
Affects Status Importance Assigned to Milestone
Nautilus
New
Unknown
nautilus (Ubuntu)
Low
Unassigned

Bug Description

Opening folders with many files takes a long time with Nautilus, to the point it becomes unusable for folders with more than 5K files.
I've measured the time it takes for folders with different amount of files to open with Nautilus and Gnome Commander. It is ~6 times faster with GC on average. In folders with ~20K files, it takes 30s with nautilus versus 6! with GC.

With Nautilus
~3500 files tales 6 seconds
~7000 files takes 18 seconds
~15000 files takes 22 seconds
~20000 files takes 30 seconds

With Gnome Commander
~3500 files tales <1 second
~7000 files takes 1.5 seconds
~15000 files takes 3 seconds
~20000 files takes 6 seconds

These are mostly small dicom files (MRI images). I am using a 8 core 3.4Ghz and 16Gigs of RAM with Ubuntu 11.04 64-bits.
Also, of course, things like selecting all files and copying them around is absurdly slow and makes nautilus unusable... but that would be another bug report (?).

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in nautilus (Ubuntu):
status: New → Confirmed
Gorka Navarrete (emrys) wrote :

With Thunar file manager things are even faster:

~3500 files takes >0.5s
~20000 files takes ~2s

This is ~15 times faster than Nautilus... and it makes a huge difference in usability. Of course, Thunar lacks some of the great features of Nautilus, but I can't see how things like a double pane should have such a big impact on speed.

Sebastien Bacher (seb128) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

Changed in nautilus (Ubuntu):
importance: Undecided → Low
Gorka Navarrete (emrys) wrote :

OK. I linked it to the upstream bug report.

Things with Ubuntu 10.10 seem to have improved. Although it depends on the content of the folders.

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.

Gorka Navarrete (emrys) wrote :

Sorry, I meant in Ubuntu 11.10.

Changed in nautilus:
importance: Unknown → Low
status: Unknown → Confirmed
Robert Roth (evfool) on 2011-10-27
Changed in nautilus (Ubuntu):
status: Confirmed → Triaged
Changed in nautilus:
importance: Low → High
Lee (qq510371827) wrote :

Nautilus 3.5.4 still has the bug. 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. In addition,gnome-bugs #356836 was filed in 2006 and hasn't been fixed until now,so why not ubuntu fix the bug by yourself? I don't know when it will be fixed if just waitting for gnome's patch.

Damián Nohales (damiannohales) wrote :

In my humble opinion, I guess if Ubuntu still rely on some upstream components (mainly Nautilus) Ubuntu going to suffer a regression in quality, mainly because the existence of Nautilus, that not accomplish usability and performance requirement to provide a good User Experience.

If GNOME continues its development as usual (removing useful and non intrusive features, adding non sense ones, not solving important issues as the present bug) Nautilus will become the worst tool for files that a user can use. Nautilus don't get a miserable part of the quality (performance, good user experience, stability) of other environments file browser (like Windows Explorer, Finder, Dolphin).

I really guess that if Canonical want Ubuntu to be a good System, needs to DROP Nautilus.

Lee (qq510371827) wrote :

This bug is somewhat related to Bug #96483(nautilus search is horribly slow ).
When you do the same things(browser files or search files) via command line it is incredibly quick to show the result. For example, in terminal, running 'ls -l xxx' command to browser a folder with many files and sub-folders or running 'locate xxx ' command to search a file in the whole file system, it shows the results without any delay.
In contrast,

Lee (qq510371827) wrote :

Sorry,i hit the submit button by mistake.Continued from previous post:
In contrast, When you browse files or search files in nautilus, it is so slow to give a response. What's worse, when you browse the same location secondly or return the search result page, it restart to do what it did the first time and give a slow response.It seems as if it did't cache the index.

Norbert (nrbrtx) wrote :

I have a folder with sub-folders (173,844 items, totalling 11.4 GB). Nautilus opens this folder very slowly.
I like Nautilus because of tortoisehg-nautilus package and simple interface.

I agree with #7.

Norbert (nrbrtx) wrote :

Forgot to write - I have disabled all Preview options in Preferences.

tags: added: natty
papukaija (papukaija) on 2012-12-18
tags: added: amd64 i386 precise quantal ubuntu
Ari (ari-lp) wrote :

This bugs persists with Ubuntu 12.04.2 LTS. I cannot fathom how an issue as drastic as this in a system component as crucial as the file manager after seven years has yet to be resolved. How can PCmanFM and Dolphin be this lightning fast compared to Nautilus?

I am not one to complain about bugs in FLOSS software as I know the volunteer time and effort that goes into developing it. This, however, is a core part of the Ubuntu and GNOME experience we are talking about and fixing the slow down should be one of the top priorities both for Canonical and the GNOME foundation.

i agree with Comment #12 - however this bug seems to be fixed in Ubuntu 12.10!
so if you don't have to use an LTS release an upgrade should give you a fast nautilus ;-)

Gorka Navarrete (emrys) wrote :

Jan, the bug is not fixed in Ubuntu 12.10 (64-bit), at least not for me.

To put a quantitative example. Imagine we open a folder with 7000 dcm files in a modern laptop:
-Nautilus takes 43 seconds
-GNOME Commander takes 1 second (!)

I tried Ubuntu 13.04 and it also takes a lot so, not fixed there neither.

Gorka Navarrete (emrys) wrote :

Of course, the 43 seconds are the default behavior. If you disable the "Show thumbnails" option in nautilus preferences, the time goes down to 3 seconds.

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?

Gorka Navarrete (emrys) wrote :

I made a stupid mistake. I was opening the same folder after changing the thumbnails option. Sorry about that.

This is a more accurate assessment. 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.

tags: added: raring
Peter L (betatester07) wrote :

Nautilus is still incredibly slow on Ubuntu 13.04...

Fabio M. Panico (fbugnon) wrote :

This bug also affects me and I agree with #15, the problem seems to be the thumbnails preview.

I have a folder with 700 small .jpg files (something between 160Kb and 400Kb), totaling 238Mb.

Nautilus:
- with thumbnails enable takes approximately 80 seconds to stop "loading" all files.
- with thumbnails disable, it only takes 4 seconds

Thunar:
- takes 1 second, it doesn't really matter (at least to my eyes) if thumbnails are enable or not.

I love Nautilus' features and integration with Gnome, but this problem has been a real pain...

(using Ubuntu 13.10 64bit, on a Core i5-3427U CPU @ 1.80GHz × 4 with 8Gb of RAM - ThinkPad X1)

nanog (sorenimpey) wrote :

This bug is still present in up to date 13.10 and 14.04. The issue is not icon previews since the same slow down occurs with small text/bin files. Given that many people have large collections of media files thisbug is a deal breaker for even casual users. It's a disaster in any kind of enterprise situation with large volume data. The problem is so bad that thunar has become part of my default install image.

Nautilus has been slow for 13 years. If Linux file browser speed can't improve with Moore's law then it is time to drop the fancy mime based "open every file and read its header" feature in my opinion. People should not be waiting 500ms for their file browser to display 10 files in 2014, all for the sake of random text files that don't have an extension and should probably be opened with a text editor anyway. In my opinion the Nautilus UI has degraded over time, and has never met the usability standards introduced by windows explorer 95/98 (not that Windows has kept them). It seems like the trend in application/OS user interface development has gone towards zero-customisability; attempting to make one UI fit the needs of both first time and power user, an impossible task. Here are some general suggestions to improve Nautilus efficiency;

- instantaneous folder browsing (options to disable mime extension reading and any other header operations which make Nautilus slow)
- the ability to add/remove standard interface buttons (eg "up folder", "home folder")
- the ability to select a real location bar (not a bubble bar)
- the ability to remove all clutter left and right of the address bar (these should be located in the View menu)
- the ability to position the address bar on its own row (the user needs to be able to see the full path at all times, even when operating with multiple unmaximised file manager windows)
- the ability to show the full path in the title bar (such that Nautilus windows containing a folder of the same name can be distinguished in the window manager taskbar)
- the ability to open a new Window (Ctrl-N) at the same location
- the ability to disable the sidebar without using dconf-editor
- the ability to add keyboard shortcuts for missing functions (eg Ctrl-G for go button operations; note in order to press Enter after a paste operation the user must move their right hand off the mouse)
- the ability to add keyboard shortcuts for existing functions, without modifying .config/nautilus/accels (eg "BackSpace" for ShellActions/Up)
- the ability to view full dates/times
- the ability to select an arbitrary application to open a txt file with
- the ability to create a new document (without modifying Templates)
- the ability to navigate the UI using the keyboard (given there is no longer a menu bar)
- the ability to stop the search bar from popping up every time the user presses a character on the keyboard
- the ability to close the search bar using the mouse (without knowing that you have to press Ctrl-f)

Skilly (michael-scheepers) wrote :

Problem persists in 14.04 LTS (Nautilus 3.10.1)

Luis Alvarado (luisalvarado) wrote :

Horrible problem in 14.04 and 14.10. It is very slow with folders that contain 500+ files (png, jpg, mp4, mkv). I tested for example a folder with 1000 files. The files were 400 png, 400 jpg, 100 mkv and 100 mp4. It was amazingly slow. Took more than 10 seconds to start showing the previews and then another 60 to 70 seconds to show all. Super slow. The ironic thing is, I have an Intel i7 4700, 32 GB of RAM and the hdd where they are is a Samsung SSD 840PRO. So there was actually no excuse for so slow performance. I can not imagine something with a normal system.

Yanpas (yanpaso) wrote :

I advise switching onto Nemo fm (fork of nautilus). It is more powerful, faster, nicer and supports gtk theme. If anybody want to do it I will post guide. As me I switched onto Xubuntu with Thunar, coz ubuntu full of such bugs

Francewhoa (francewhoa) wrote :

Confirming this bug is still present with:
* Nautilus: 3.4.2-1+build1
* Debian: Wheezy 7.7 at 64 bit
* Gnome: Version 3.4.2
* Intel Core: i7-3770S CPU @ 3.10GHz × 8
* Ram: 16 GB

Francewhoa (francewhoa) wrote :

Confirming this bug. I created a bug report at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767276

mmalmeida (mmalmeida) wrote :

I confirm this. It is extremely slow to load picture folders with thumbnails.

Francewhoa (francewhoa) wrote :
Laurent Dinclaux (dreadlox) wrote :

Deleteing gvfs-metadatas fixed it for me (as a workaround)

rm -rf /home/YOUR-USERNAME-HERE/.local/share/gvfs-metadata
pkill gvfsd-metadata

As per https://wiki.debian.org/Nautilus/FAQ/SlowNautilus

mmalmeida (mmalmeida) wrote :

That workaround did not work for me.

alemù (alemuggianu) on 2015-03-02
Changed in nautilus (Ubuntu):
status: Triaged → Incomplete
status: Incomplete → Confirmed
alemù (alemuggianu) wrote :

Sorry, I accidentally edited the Status of the bug (for ubuntu) from Triaged to Incomplete.

I can't change it back because I'm not the bug supervisor, I'm going to change it to Confirmed, sorry again.

Ajith R Nair (trytoinnovate) wrote :

Bug still present: its taking more time to load the folder containing 500+ images

Distributor ID: Ubuntu
Description: Ubuntu 14.04.2 LTS
Release: 14.04
Codename: trusty

Hardware:
Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 8Gb memory, 1TB HDD

Changed in nautilus:
status: Confirmed → Invalid
Changed in nautilus:
importance: High → Unknown
status: Invalid → Unknown
Changed in nautilus:
importance: Unknown → Medium
status: Unknown → Confirmed
Changed in nautilus:
status: Confirmed → Invalid
Sandeep C (meetsc) wrote :

I also face this issue.

Bao Nguyen (baona119) wrote :

2018 now and nothing has changed.

Christof Schöch (c-schoech) wrote :

I would like to confirm that this bug is still there (Ubuntu 17.10, Nautilus / Files 3.26.0).

Deepinthekernel (mark-winder4) wrote :

I so agree with richardbrucebaxter on this. When I switched all my computers from Windows 98 to Linux in the late 90's this was the biggest practical difference. Now I know its not Linux or the file system but Nautilus that is the problem. Its exactly the same today, load up a large file on a windows system, bang its in your face, right there. On Ubuntu, it several minutes wait. This is a daily thing for me.

I hear all the arguments that say its bad practice to have large directories, but sorry I need to do this and if other file managers can cope why not Nautilus?

There are many avenues of attack, from better caching, to mult-thread, to prioritization, but this should be fixed. Now we have many file systems that are as fast as they get in this situation, Nautilus just sits on the sidelines, its a terrible shame.

Linked to this, the whole thumbnail mechanism in Nautilus is broken, because thumbnails are stored in one place per PC, when its obviously better to store locally as windows does, so that if you make a copy of a dirctory with a new name this metadata just gets copied and does not have to be recalculated. It should also be that tif you move a directory, there is no need to recalculate thumbnail metadata.

Most importantly, some of these things (large directories, local thumbnails etc) are important to some people and not important to others. Nautilus should be easily configurable to meet the needs of users and users who need this stuff should be catered for, not told that your use case is unimportant or bad practice, this argument is a circular tautology (defines itself to be true).

Please, Nautilus is a central part of the usability of Linux, please could it not be stuck in the 90's ? Please could this be given some priority, even if it is "hard".

Gorka Navarrete (emrys) wrote :

OLD link fails

Changed in nautilus:
importance: Medium → Unknown
status: Invalid → Unknown
Gorka Navarrete (emrys) wrote :

Adding what it seems to be the related upstream bug report now:
https://gitlab.gnome.org/GNOME/nautilus/issues/978

Maybe we should discuss there, so we are not screaming to the void?

Changed in nautilus:
status: Unknown → New
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.