KFileItem, mime types, and icons

[Frank Reininghaus]

Hi David!

2013/6/11 David Faure:
> Le vendredi 7 juin 2013 11:37:18 Frank Reininghaus a écrit :
>> This sounds reasonable! And if the visible icons are fully determined
>> in 200 ms, maybe we should use the remaining time to try and do a fast
>> icon loading (without determineMimeType()) for all other items, to
>> reduce the risk that the user ever sees "unknown" icons when
>> scrolling.
>
> Sounds good.
>
>> But I think that even the time that we spend on fast icon loading must
>> be limited, because "fast" icon loading in directories like
>> /usr/include/ and /usr/lib/ takes several seconds here. Even in
>> /usr/share/, which consists of 520 subfolders and only 4 files here,
>> calling iconName() for all file items takes almost 6 seconds(!).
>
> callgrind to the rescue :-)
>
>> I'm wondering if something goes wrong there - it seems that "fast"
>> icon loading is particularly slow for folders, even though I would
>> expect that loading the plain folder icon should be relatively easy.
>
> This is surprising indeed, given the cache in kiconloader. Needs profiling,
> either with callgrind or the poor-man's profiler (interrupting gdb at random
> points in time).

Thanks for the hint! The "Poor Man's Profiling" technique was unknown
to me so far, but it is indeed very simple and effective :-)

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. 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*).

I'm not really familiar with these kdelibs internals, so I don't know
if it's possible to change this without breaking other stuff. Do you
have an idea? If it appears too difficult or to dangerous to change it
in kdelibs, the last option would be to implement a rather hackish
function in Dolphin, because I would really like to resolve this
stupid "unknown icons" issue once and for all:

QString fastIconName(const KFileItem& item)
{
    if (item.isDir()) {
        return QLatin1String("inode-directory");
    } else {
        return item.iconName();
}

Thanks and best regards,
Frank