After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 682836 - possible performance regression with large directories
possible performance regression with large directories
Status: RESOLVED OBSOLETE
Product: nautilus
Classification: Core
Component: general
3.5.x
Other Linux
: High critical
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks: 680982
 
 
Reported: 2012-08-27 23:22 UTC by William Jon McCann
Modified: 2021-06-18 15:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
strace log by "strace -ttt -f ..." after striping (82.95 KB, text/plain)
2013-02-06 08:11 UTC, YE Qianchuan
  Details
A quick fix, may causes other problems (940 bytes, patch)
2013-02-06 08:28 UTC, YE Qianchuan
needs-work Details | Review

Description William Jon McCann 2012-08-27 23:22:03 UTC
We've heard about and experienced a possible performance regression with loading large directories. We should figure out what is going on.
Comment 1 William Jon McCann 2012-08-31 17:16:51 UTC
Suspect is a11y but needs to be profiled.
Comment 2 William Jon McCann 2012-09-19 15:58:59 UTC
This bug is based on anecdotal evidence that things got a bit worse in the last few months. This was before the redesign effort began. One thing that changed that may impact performance in list view is the use of an ellipsizing Name column.

We have a very old bug (with many dups) that is related (bug 356836).

We may also want to investigate using fixed height mode. But as I understand it that is not an option since our column widths are not fixed.
Comment 3 Matthias Clasen 2012-09-21 21:37:26 UTC
Moving off the blocker list.
Certainly warrants closer investigation, but probably not delaying the release.
Comment 4 Vidar Braut Haarr 2013-01-27 11:05:43 UTC
This should block again.

The real problem becomes apparent when you have a folder with hundreds (400+ in my case) video files and some subfolders.

1. Open the main folder
2. Notice the "Loading..." status bar thing with the spinner in the lower right corner
3. Try to open a subfolder while the "Loading"-bar is still showing.

Results: Crash.

This result is consistent for me with 3.7.4 and has been for quite some time now.

Before it was just slow, but now it's a real blocker.
Comment 5 André Klapper 2013-01-27 11:47:58 UTC
(In reply to comment #4)
> Results: Crash.

Without a stack trace from the crash it's very hard to determine what caused it.
Can you get us a stack trace? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance!
Comment 6 YE Qianchuan 2013-02-06 08:11:33 UTC
Created attachment 235290 [details]
strace log by "strace -ttt -f ..." after striping

Run "strace -ttt -f nautilus-strace nautilus", and finally run "grep MARK nautilus-strace > nautilus-strace-strip" to generate this log. Can use plot-timeline.py to visulize it.

What I did after launching nautilus was type /usr/bin (contains 2967 files and directories) in the location bar and wait for about 20 seconds until files showed up.

It may help.
Comment 7 YE Qianchuan 2013-02-06 08:28:06 UTC
Created attachment 235291 [details] [review]
A quick fix, may causes other problems

I made a quick look at the source and found the following statements:

	if (! view->details->loading || nautilus_directory_are_all_files_seen (directory)) {
		schedule_timeout_display_of_pending_files (view, view->details->update_interval);
	}

I guess it causes program display files after all files are loaded, rather than immediately display a few files.

Remove this if statement seems work for me, now nautilus continually display files while loading. But I'm not quite clear with internal of nautilus, so I guess it may also result in other bugs.
Comment 8 Bastien Nocera 2014-05-28 12:41:40 UTC
The original bug still stands. The crasher is unrelated and should be filed separately.
Comment 9 Carlos Soriano 2016-03-01 18:38:44 UTC
Review of attachment 235291 [details] [review]:

Thanks for the patch, I think this is indeed one of the roots of the problem. However we cannot do that since it will cause even more jumps while the user is navigating.

So this patch needs works.

fwiw I'm actually looking at this as well for some selection issue while searching.
Comment 10 garrett.mitchener 2018-09-19 17:25:55 UTC
Related bug report and conversation:

https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/869793
Comment 11 André Klapper 2021-06-18 15:56:00 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org (resources are unfortunately quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version of Files (nautilus), then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/nautilus/-/issues/

Thank you for your understanding and your help.