ginormous performance issue

[Marco Martin]

Hi all,
talking with Alexis at akademy, we figured out something realy horrible was 
happening during the caching of plasma svgs, because when an applet is 
quickly resized, plasma cpu and disk usage spikes, actually passing all the 
time compressing images and writing them to the disk.
so i looked a bit at it and found this
http://websvn.kde.org/trunk/KDE/kdelibs/plasma/framesvg.cpp?r1=970932&r2=975773

this commit made the code cleaner, but totally defies the concept of delayed 
cache writing, in fact it writes all of the images asked to be inserted into 
the cache. why is bad?
because if an applet is resized, every rendered svg will be inserted into the 
cache, from start size to end size of the drag resize.
all the middle sizes are totally useless in term of the purpose of the cache 
(they won't be needed in the future) and case a tremendous cpu usage 
(valgrind, oprofile,whatever will say that 99% of the time is spent inside 
zlib, compressing the stuff to put into the hard drive, wee :))

the attached patch is an horrid kludge, but kinda fixes the problem
it removes from the pixmaps to be inserted all the ones that starts with the 
same piece of key, so all the ones with the same path, when a new pixmap is 
inserted.
of course this is ugly, but the result is fuckingly faster...

now, what could be a proper way to do it (without having to change the api, 
sigh)?

a way could be like now, parsing the key and throwing away other sizes of the 
same framesvg, or just revert that commit...
the issue is kinda urgent, because kde4.3 is affected too, so someting 
backportable should be quickly found...

Cheers,
Marco Martin
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: delayedcache.diff
Type: text/x-patch
Size: 2173 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090715/bba4eb47/attachment.diff