I can wait almost 5 seconds to access the directory, during which Dolphin entirely freezes (the STOP kind of hang). Is anyone else with a similarly large directory experiencing this? If so, have you any potential solutions for me?
Relevantly, is there a reason that it doesn’t seem to load them dynamically? (To ensure that the user doesn’t accidentally freak about a directory or file being absent, perhaps?)
I didn’t think it was many, considering how many a photographer must take during their work. I know some who just leave them completely unorganized…
Anyway, I’m embarassed to say that I didn’t consider disabling Preview, but relieved to say that it’s unfortunately not the cause. It didn’t change anything at all.
Please report a bug with details so that somebody else could reproduce your situation.
Number of files (7k), total size(32GB), numbers of directly average file size(~4.5MB), what kind of drive (SSD or HDD) and filesystem (ext4, smb, nfs…?).
And your distro + versions.
If you have the time and some technical skill I would suggest you to try to observe the 5s freeze with hotspot and extract a flamegraph matching the freeze time-window. That method will for sure diagnose the issue origin.
The perf.data is specific to your distro can’t be exported unfortunately only to the same distro with the same exact packages.
I am interested in the “Flame Graph” tab mostly. It will tell what was dolphin doing.
It does require debug symbols, it seems you have them or at least a bunch.
Since you are using fedora 40, you can simply once launch gdb dolphin and it will download them for you: type once c, wait a bunch during download and once dolphin opens you can close it, the debug symbols are downloaded.
At least we can see the dolphin main-thread very busy, that would make it unresponsive in the Time line".
You put in effort to assist me. It’s fair. Regardless, it’s not going to be solved unless I put some work in, and acquiring the data was also surprisingly intuitive. You’ve recommended a good tool.
yes i have had this issue for as long as i have used dolphin. it seems that gnome/gtk has optimized something much better and doesn’t scrape all the directories every time you open them like kde does. i can literally hear it trash through my hdds every single time i open something with couple thousands of files but gnome has the file lists cached so that never happens and the listing opens instantly.
these programs really need to promote their support sections better so people can actually report issues like this
how? i saw this recommended elsewhere but you literally can’t, at least not in dolphin settings and no scrolling the 5 mib limit wont turn it off but instead removes the limit completely and generates previews for everything. i also read that each file gets probed for things like type which is part of what makes the process so god damn slow
Considering that @meven correctly pinpointed my issue to a specific attribute column’s visibility, and the fact that it was due to a recent commit, I expect that your issue is different. However, using the information from the previous discussion, would you be able to provide a flame graph for your issue, as I have? I ask because that would demonstrate, without doubt, whether it differs.
Assistance
Are you aware of every KDE application’s “Help” pages?
These display ways to report bugs. However, I agree that they should link to their relevant application’s section on this Discourse forum. I’ll propose it, if you don’t want to first (if you do, please link that here).
Window Screenshots
If you utilize spectacle’s “Active Window” mode, you shan’t need to crop screenshots of specific windows:
uhh turns out that getting the debug symbols for debian is a bit more complicated but i’ll try figure it out as this has been driving me insane a long time
@meow, yeah, that’s one of the reasons I went for Fedora rather than Debian. Does gdb’s debuginfo option work? That might at least supplement it if you can’t install the relevant *-debuginfo packages:
RokeJulianLockhart@sayw4i:~$ gdb dolphin
GNU gdb (Fedora Linux) 14.2-1.fc40
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from dolphin...
Reading symbols from /usr/lib/debug/usr/bin/dolphin-24.02.2-2.fc40.x86_64.debug...
(gdb) run
Starting program: /usr/bin/dolphin
This GDB supports auto-downloading debuginfo from the following URLs:
<https://debuginfod.fedoraproject.org/>
Enable debuginfod for this session? (y or [n]) y
i figured out that there was a different repository that needed to be added to get the symbol packages so thats sorted now. is this graph any good or do i need to install more stuff?
@meow, the “??” prefixes on some of the stacks would demonstrate to me that some symbols are absent, but I’m novice at this. You might want to check that all relevant packages are installed (do try running gdb with debuginfo enabled, if you haven’t - it works well). Except that, I’ll defer to someone else with more experience.
Regardless, thanks for the report. If your issue is similar to mine, the more corroboration, the better!
You put in effort to assist me. It’s fair. Regardless, it’s not going to be solved unless I put some work in, and acquiring the data was also surprisingly intuitive. You’ve recommended a good tool.
