[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: KFileItem, mime types, and icons
From:       Frank Reininghaus <frank78ac () googlemail ! com>
Date:       2013-06-13 20:41:46
Message-ID: CAFoZWWhUDhk_4Kh0JRYJZiEsYcynSLM6b_3eC=McmMaPuiiF5w () mail ! gmail ! com
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]