Review Request 124811: KIconLoader: speed up hasIcon/iconPath by using the on-disk cache from loadIcon

[Volker Krause]

> On Aug. 20, 2015, 4:54 p.m., Volker Krause wrote:
> > Sorry, still doesn't seem to fix KMail's QIcon::fromTheme() usage here, hits the disk as before.

IIUC insertion into the persistent cache only happens when actually rendering the icon, right? I am trying to debug this with KMail, my current theory is that what I'm seeing here are actually only icons that are created but never rendered (considering the depth of KMail's menus and dialogs, that are actually quite a few). I always measure the second run of KMail on a clean cache, so it would actually never insert the non-rendered icons into the cache.


- Volker


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124811/#review84095
-----------------------------------------------------------


On Aug. 20, 2015, 8:07 a.m., David Faure wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124811/
> -----------------------------------------------------------
> 
> (Updated Aug. 20, 2015, 8:07 a.m.)
> 
> 
> Review request for KDE Frameworks and Christoph Feck.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> -------
> 
> This makes QIcon::fromTheme() much faster, for all cases where we have loaded the
> icon once before (including in another process).
> 
> 
> Diffs
> -----
> 
>   autotests/kiconloader_unittest.cpp 6b60e7ebfc970c94ae865d56c4e33a8034b4fcee 
>   src/kiconloader.cpp db3aa8f8fd6f8fb706edcb27cce073c36831934d 
> 
> Diff: https://git.reviewboard.kde.org/r/124811/diff/
> 
> 
> Testing
> -------
> 
> The unittest has a way to see if KIconLoader used the cache or searched on disk, with the newly exported global int. I couldn't think of a better way.
> 
> I'll let Volker do the real-world testing and measure the overall impact as he did previously.
> 
> 
> Thanks,
> 
> David Faure
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150820/639b40e7/attachment.html>