ginormous performance issue

Marco Martin notmart at gmail.com
Wed Jul 15 23:45:42 CEST 2009


On Wednesday 15 July 2009, Martin Gräßlin wrote:
> Am Mittwoch 15 Juli 2009 23:06:42 schrieb 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=
> >97 5773
> >
> > 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...
>
> that could explain why Aurorae engine is terrible slow when resizing
> windows. So please don't fix it in Theme but directly in FrameSvg as it is
> not only used in Theme.
hmm, framesvg uses theme anyways to save svgs, so a fix anywhere should fix 
it..


More information about the Plasma-devel mailing list