(very) strange fix for slow change directory performance some people experience (could help find a fix?)

[Rui Mesquita]

Binary package hint: nautilus

Hi

I have been using Ubuntu at least since Dapper, and always experienced varying degrees of slowness in nautilus, be it right after a reboot like with Hardy for me, or only after a few hours of somewhat intensive file browsing/management. Perhaps Feisty was the fastest for me in this regard, and the only one which I had as fresh install (excepting user files), even Dapper I dist-upgraded it straight from a fresh ubuntu 5.10 install to one of the later Dapper betas. Hardy has been the one with the worst performance from nautilus, for me at least.

OK, so I am aware most people have no performance problems with nautilus, but if you search ubuntuforums.org for post titles mentioning nautilus you will see a lot of them are about poor performance/slowness in nautilus.

Steps to reproduce this 'fix':
 'Normal' behaviour:
 - Nautilus takes more than a few seconds to start responding (while freezing all open nautilus windows) when the user changes directories, regardless if the user is changing to an empty directory, one full of pictures or directories. (This has nothing to do with reading and displaying cached thumbnails, that comes *after* the nautilus had stopped responding.)

 Reproducing the fix:
 - For best results, find a folder that doesn't take to long after the 'normal' nautilus change dir freeze to stop loading, i.e., the red stop button in nautilus turns gray instantly. A directory which contains only a few dozen folders and nothing else is ideal.
 - Change into a sub folder that as at least one file renamable by you, or create a file yourself
 - Now, create a file, or rename an existing one from the context menu -> 'Rename', you don't need to actually change anything in the name, but just leave the inline editable lable as if you were just trying to come up with a name for the file, but don't touch it!
 - With name lable for that file still in edit mode, click on the up directory button in nautilus

 Result:
 - Nautilus changes to the parent directory and finishes loading it, instantly! Impossible! :)

 Expected Result:
 - It would take more than a couple of seconds to change directories.

Would it possible please to find out how to reproduce this 'erroneous' behaviour with regular usage? :)

[Sebastien Bacher (seb128)]

thank you for your bug report, could you describe easy steps to trigger the issue? do you get the bug on a stock installation? the description suggest something that's rather a speed perception issue and it might be tricky to figure if there is actually a bug there, could you report the bug on bugzilla.gnome.org, upstream might have a better idea about the issue

[Rui Mesquita (rpedro78)]

Simplified steps:

 1. Create a new directory, say, named 'folder0'
 2. Inside it, create another one, 'folder1'. And inside it, another one, 'folder9'
 3. Go in 'folder0' and then 'folder1' again, maybe by clicking on the 'up' button to go back, and then clicking 'folder1', or double clicking if that's how you have nautilus set up
 4. Do this a few times, take note how fast it is to show each directory's contents
 5. Go in 'folder1'
 6. With 'folder9' selected, press F2 on the keyboard, 'folder9' should be in rename mode. Leave it like that
 7. Without doing anything else, click on the 'up' button
 8. Take note how long it takes to show 'folder1' inside 'folder0', for me it's instantaneous
 9. If it took more than a couple of seconds to show 'folder0''s contents before, the difference should be very noticeable, enormous

[Rui Mesquita (rpedro78)]

I have looked at some nautilus bugs related to slowness at bugzilla.gnome.org, found 2 or 3 (1 duplicate maybe), and they aren't the same thing. Specifically they are related to how long nautilus takes to display the files in a directory with 1000+ files, and I can confirm that same problem here. On the other hand, the problem I reported with this bug is about how long nautilus, all the windows, not just the one where the operation is performed, takes to start responding again after the user does a change directory command. The other bugs I saw at bugzilla.gnome.org take place after this one, in other words, while that one window is still crunching to show all those files, all the other nautilus windows are responsive, I can change directories, open files, whatever, without that one nautilus window getting in the way.

About the steps I posted, the speed difference is very noticeable. Just fresh after a reboot the difference between the steps I described and normal behaviour might just be a little under a second or a bit more, still very noticeable. After a few days of having opened a lot of nautilus windows, the difference is something like between ~5 to ~8 seconds for me, to instantaneous, to open each and every folder. It is far from having to do with perception, believe me, it makes it a real pain to use nautilus to do anything related to file management.

[Sebastien Bacher (seb128)]

you seem to be the only one to have a such issue, could you open it on directly on bugzilla.gnome.org directly since you can reply to their comments where other people who don't have the bug can't not easily

[Pedro Villavicencio (pedro)]

any news about it? did you opened the bug upstream?

[Rui Mesquita (rpedro78)]

I submited a report at the gnome bugzilla,

http://bugzilla.gnome.org/show_bug.cgi?id=546920

[Sebastien Bacher (seb128)]

thank you for sending the issue to GNOME

[trevor t (launch-etjt)]

On Intrepid I also experience Nautilus "not responding", with one CPU (2.4GHz Quad) at 100% for several minutes.

I suspect it is enumerating and caching every item in every subfolder, because the time varies. E.g. /usr takes a looong time, while Documents doesn't.

I don't really need to know how many items are in every single folder, Maybe that could be made an option; tradeoff detail for speed.

[vocx (eliudcabrera)]

Please see if this is not a duplicate of bug #159042

Specifically, try to reproduce this bug with Assistive Technologies turned off.

Also notice if you are using "List View".

[Sebastien Bacher (seb128)]

The bug is old and Ubuntu changed quite a lot since, there has also been no activity here nor similar reports. Closing since we believe the issue as described is deprecated but feel free to file a new report if you still have problems in recent Ubuntu versions.