From kfm-devel Thu Jun 13 20:41:46 2013 From: Frank Reininghaus Date: Thu, 13 Jun 2013 20:41:46 +0000 To: kfm-devel Subject: Re: KFileItem, mime types, and icons Message-Id: X-MARC-Message: https://marc.info/?l=kfm-devel&m=137115612512226 Hi David, 2013/6/12 David Faure: >> Thanks for the hint! The "Poor Man's Profiling" technique was unknown >> to me so far, but it is indeed very simple and effective :-) > > Hehe, it's rather intuitive though: "what is that program doing right now?" :) I did use this technique earlier for frozen applications, to find out where in the code the freezing happens. It never occurred to me that you can also use it to debug things which are slow. But it's indeed intuitive that interrupting at random points will finally take you to the right place :-) >> Program received signal SIGTSTP, Stopped (user). >> 0x00007ffff14e1a17 in access () from /lib64/libc.so.6 >> (gdb) bt >> #0 0x00007ffff14e1a17 in access () from /lib64/libc.so.6 >> #1 0x00007ffff2bd4d9a in KStandardDirs::exists (fullPath=...) at >> /home/kde-devel/kde/src/KDE/kdelibs/kdecore/kernel/kstandarddirs.cpp:593 >> #2 0x00007ffff2be9b22 in KFolderMimeTypePrivate::iconName >> (this=0xeaaf40, _url=...) at >> /home/kde-devel/kde/src/KDE/kdelibs/kdecore/services/kfoldermimetype.cpp:92 >> #3 0x00007ffff2bf0b4b in KMimeType::iconName (this=0xd85fa0, url=...) >> at /home/kde-devel/kde/src/KDE/kdelibs/kdecore/services/kmimetype.cpp:605 >> #4 0x00007ffff5ef77e6 in KFileItem::iconName (this=0x7fffffffb990) at >> /home/kde-devel/kde/src/KDE/kdelibs/kio/kio/kfileitem.cpp:921 >> >> It seems that it tries to access the directory on disk to see if there >> might be a .desktop file to read an icon name from. > > A .directory file, more precisely. > >> This is not quite >> what I would have expected - after all, the point of calling >> KFileItem::iconName() without a previous determineMimeType() was to do >> it fast, without disk access (and that's apparently also what happens >> when calling iconName() for *files*). > > Yep. > This is very very close to my recent fix for slow mounts, except that we want > the same in all cases. So just removing checks for "is it slow" would do. > Can you test this patch? It works fine for me! I can confirm that the "right" icons are shown eventually when iconName() is called again after determineMimeType(). And I never observed any slowness when calling iconName() with your patch. What I actually did was to enter a directory and then just call iconName() for all items reported by the dir lister, and see how long that takes. However, I must say that making reliable measurements and "with patch"/"without patch" comparisons is not quite possible for me. It seems that the caching done by the kernel prevents that I see slowness again for a directory that I visited once, even if I do it with a different user the second time. I will post a Dolphin patch that makes use of this later today or tomorrow. Thanks for your work! Frank