Bug 240009

access(2) is not called directly, this is related to trying to find a named icon by searching through a list of icon directories (similar to how a shell would search PATH for an executable).

The best solution is probably to make KIconLoader resolve all icon names at once and then remember where they were stored for later use instead of searching for non-cached icons. The intermediate solution that has been established for KDE SC 4.5 is to not load icons in certain situations where all we wanted was a size, and to reduce the amount of paths searched for icons.

The wording in the man-page for access is confusing. What it means, is that one should not use access() to determine if a user is authorized to open a file, thus creating a security race condition. However all other reasons to use access are fine! This is what it means by "for this reason", it means "the use for this particular reason".

Anyway, why looking at this I found some interesting code paths to optimize. Commit follows.

SVN commit 1164379 by dfaure:

Optimizations:
- Remove duplicates in the list of paths, before checking every path for icon themes
- Add missing slash, so that we don't look for /usr/share/pixmapsoxygen (doh)
- Factorize the code that looks for index.desktop or index.theme so that we call access+stat only once.

Results of strace -e trace=open,access,stat ./kiconloader_unittest >& log:
 Before: 82598 * access, 22518 * stat, 1082 * open
  After: 73798 * access, 16694 * stat, 1082 * open

CCMAIL: kde-optimize@kde.org
CCBUG: 240009


 M  +4 -3      kiconcache.cpp  
 M  +17 -16    kicontheme.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1164379

SVN commit 1164381 by dfaure:

Look for index.theme before index.desktop.
New results:
After: 73750 * access, 16678 * stat, 1082 * open
CCBUG: 240009


 M  +5 -5      kicontheme.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1164381

Confirming bug still exists in KDE 4.5.3.  Opening a folder takes around five seconds, even when there are only a few files in it.

Still present in KDE-4.5.5. I'm waiting about 20 s if SaveAs was issued the first time. This might be also due to many deep directories in my home dir. And I don't see any benefit to have e.g. kate to scan the whole structure recursively at once, if the normal use case is to save a file within a certain directory.

Whether this is related or not I don't know, but in 4.6.0 (openSUSE 11.4), clicking the save button in KSnapshot the very first time as a new $USER can take an excruciating length of time to get the file dialog open if /etc/fstab has a lot of noauto NFS and/or CIFS entries, as the filepicker tries to populate the left pane for each of them mounted or not. After the first time it's somewhat less slow, but still far from acceptably responsive. Many of the line items in fstab (e.g. those lacking a previously created mountpoint dir) cause a QDBusConnectionPrivate::connectSignal .xsession-error entry.

Ugh, this is even worse when accessing files through sshfs.  It looks like one of the reasons why it's so damn slow is it's trying to load those stupid icons for each file.

(In reply to comment #8)
> Ugh, this is even worse when accessing files through sshfs.  It looks like one
> of the reasons why it's so damn slow is it's trying to load those stupid icons
> for each file.

Using KDE 4.6.3 with Kate 3.6.3.

Is this why the folder selection dialog in Backintime is dead slow as well? I can sometimes wait minutes before I can select folders, or when I have clicked on a folder (selecting where to save snapshots in config, something you do seldom). Scrolling typically takes 20 seconds to respond.

I'm just curious as to why this isn't a high priority bug?  This bug is _very_ annoying and it affects file selection boxes on any kde program.

I second  the opinion of Matthew Schultz. This bug is terrible, I wish I could use the GTK file dialog on KDE apps! When it happens I don't even know whether the application will awake some minutes later or if I should kill it as it won't come back, there's no obvious way to know.

If anyone is having trouble to reproduce it, try to save something into a folder that already has lots of files, like about two thousand (such as /usr/bin in a usual install I guess). Or saving something there for a second time, I have the impression that it will sometimes work find "once" for a folder and then it will just tend to hang forever (even after reboot).

A workaround is to save things folders that are not that full and move it via command line or file manager afterwards. In some programs you can change its "folder history" on its rc file, so if there's a program that's always going to hang because its last used folder is very full, you can edit it manually to a subfolder of that folder or its container folder, whatever.

My own bug report https://bugs.kde.org/show_bug.cgi?id=346403 might be a duplicate of this one.

If it really is caused by the same code, then there is some interesting trivia I can add to this bug report.

First, the bug only occurs if the initial directory of the file dialogue is the one containing a lot of files. Specifying a different initial directory and then navigating to the big directory works fine.

Second, the bug does not occur with dolphin. Compare:

dolphin really/big/directory/

with

kdialog --getopenfilename really/big/directory/

This holds both true for dolphin 15.08.0 and dolphin 14.12.3 (Development Platform 4.14.11). I currently have no Qt5/KF5 kdialog around, so the version being used for the test was kdialog 1.0 (Development Platform 4.14.11).

Again, I'm not sure if this is the original bug or a different one. The symptoms sound familiar, and it's a common component, but it has been more than five years since the initial report in which Qt, KDE and computers changed, so the symptoms might have as well. (I remember the performance issue was more severe on my netbook, where it would render the file selection unavailable for up to two minutes in a folder with >800 files, but on my new SSD i7 ultrabook it's about 20 seconds with ~1350 files.)

This bug still exists in KDE 5. I think a reasonable solution would be to display the files and directories first with generic icons and look for more appropriate icons on the background.

The file dialog is *extremely* slow if / is NFS mounted.