GNOME Bugzilla – Bug 682836
possible performance regression with large directories
Last modified: 2021-06-18 15:56:00 UTC
We've heard about and experienced a possible performance regression with loading large directories. We should figure out what is going on.
Suspect is a11y but needs to be profiled.
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.
Moving off the blocker list. Certainly warrants closer investigation, but probably not delaying the release.
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.
(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!
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.
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.
The original bug still stands. The crasher is unrelated and should be filed separately.
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.
Related bug report and conversation: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/869793
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.