Created attachment 183020 [details] perf report --stdio -g graph,8 --sort comm,dso -i xdgdp.profile.raw | c++filt Here's an outline of what I _suspect_ is happening based on the circumstances. The use case is a filesystem 'directory' as a database for uniquely storing files by human-readable filenames. I am very aware that there are far too many files, to the point that overlayfs is used to make a union of several directories. This is an extreme case that happens to expose an inherent design flaw that most probably don't realize is a flaw due to far less files where things are saved / loaded. My case happens to involve ~16000 files in the union folder. Sadly there isn't a better way of keeping them unique based on the key that is a filename, any other interface would at least require duplicate network transfers when a unique name already exists and they'd be avoided. STEPS TO REPRODUCE: 1. Have 'many thousands' of non-trivially big files of various sorts in a catalog that is one logical folder. OverlayFS use optional. 2. Use xdg-desktop-portal-kde (E.G. from Firefox with the config values to force the use of KDE's desktop-portal) to try to save a file. OBSERVED RESULT 3. Watch firefox (or application) freeze for _several tens of seconds_ as every file is Statted and Mime Type checked, etc for the tree view dialog updates. EXPECTED RESULT Save the file and also ABORT ALL DIALOG UPDATES Bonus result: only stat / update files that match or contain the filename. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.4.1 (with updated xdg-desktop-portal-kde for debug symbols download) KDE Frameworks Version: 6.15.0 Qt Version: 6.9.1 Kernel Version: 6.15.4-arch2-1 (64-bit) Graphics Platform: Wayland ADDITIONAL INFORMATION I saved _two_ files during this capture. perf report --stdio -g graph,8 --sort comm,dso -i xdgdp.profile.raw | c++filt
Note this can also be observed on E.G. a slower remote filesystem with a more reasonable number of files to stat. Probably also via an SSHFS mount (where every call has a notably higher round trip).
Possibly related files? This function seems to fire off 'directory listings' which continue to churn in the background even after the dialog is finished. IMO this is an error. There's no limit to the number of results cached, nor a work cancel on dialog close. https://invent.kde.org/frameworks/kio/-/blob/master/src/core/kcoredirlister.cpp?ref_type=heads#L587 Similarly there's no limit, nor a way of checking the directory for a single name we already have (or that the user updates within the dialog). https://invent.kde.org/frameworks/kio/-/blob/master/src/core/listjob.cpp?ref_type=heads However, curiously, I don't know what really changed to make things suddenly so much worse. My new computer is way beefier, tons of RAM, to the point where I'm comfortable using btrfs compress=zstd and zram-generator ( https://wiki.archlinux.org/title/Zram ).
After system updates I don't notice the huge performance impact anymore. The design seems to still be the same. Rather than only updating what's actively displayed it's likely processing the whole directory. However it's less than one second of impact even in my worst case directory. Operating System: Arch Linux KDE Plasma Version: 6.4.3 KDE Frameworks Version: 6.16.0 Qt Version: 6.9.1 Kernel Version: 6.15.7-arch1-1 (64-bit) Graphics Platform: Wayland Not sure if it's the .3 (over .2) for KDE Plasma or the kernel update that restored historic behavior.
I'm glad to see you're no longer experiencing the interface performance lag. I'll close this out for now. If the problem comes back, feel free to reopen this report. Thanks!