[PATCH] Cache returned KIconLoader pixmaps in 4.5.2

[Matthias Fuchs]

Am Montag 13 September 2010, 04:57:18 schrieb Michael Pyne:
> On Monday, September 13, 2010 00:20:40 Matthias Fuchs wrote:
> > Works really great now. I have a question though:
> > 
> > When running my small test program the icon gets cached and then reused,
> > though if I run the test again -- i.e. start the program again -- it gets
> > also cached again and then reused, but shouldn't it still be in the cache
> > from running the program the first time?
> > Or does the cache gets cleaned up very fast?
> 
> Define "cache". There are two:
> 
> 1. A process-shared cache, but the catch is that the data must still be
> decoded from PNG (which is how both QImage and QPixmap stream it to
> storage). 2. A process-local pixmap cache. This essentially stores
> references to the QPixmap that had been read from cache 1 so that it is
> easy to refer to in the future. These pixmaps are already in either X
> server or GPU memory which is why they're much faster.

Is there a specific reason the pixmap cache is process-local instead of 
process-shared? The reason I am asking this is that the creation is very 
expensive as noticed before.


In any case the attached patch speeds up a warm pixmap cache by 25%, I know 
looking up is very fast already but imo this patch does not make the code 
harder to understand but still gives a small speed gain.


Cheers!
matthias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kiconloader.diff
Type: text/x-patch
Size: 1546 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100913/d1933291/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100913/d1933291/attachment.sig>