ginormous performance issue

[Marco Martin]

On Thursday 16 July 2009, Marco Martin wrote:
> On Thursday 16 July 2009, Aaron J. Seigo wrote:
> > On Wednesday 15 July 2009, Marco Martin wrote:
> > > a way could be like now, parsing the key and throwing away other sizes
> > > of the same framesvg, or just revert that commit...
> >
> > i think the patch you attached will also kill other valid pixmaps to be
> > cached: two plasmoids with the same svg but rendered at different sizes
> > == only one gets cached == not good.
> >
> > sooo .. yes, that commit should probably just be reverted. unfortunate,
> > as it means more overhead per FrameSvg object which is something that is
> > used quite a lot.
> >
> > some per-caching-object accounting in Theme could help prevent this (and
> > others from falling into the same trap) but that's more work and similar
> > overhead (not to mention API changes)...
> >
> > +1 on reverting.
>
> ok, i'll revert (at least for 4.3), too bad because the code is way more
> clean now :(
> what would be better is theme::insertIntoCache(const QString& key, const
> QPixmap& pix, QObject *sender)
> but api change, big nono
> sigh :(
>
> but a sick idea come to my mind: what about encoding the pointer value (or
> another random number, whatever) into the key? :p
> a key will have the form
> 7635865:path_300_200_blahblah
>
> in the cache only stuff after : will be saved as key, the first part (that
> can't be saved since wll change between sessions) just used to discard the
> useless ones :)

here we go, now only problem i see besides looking a bit perverse is assuming 
a length for the pointer (is there a way to make this always correct? 
otherwise another random number could be picked)
and assuming that the key is done this way, there should be some sort of 
fallback to the old key?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: delayedcache2.diff
Type: text/x-patch
Size: 4671 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090716/1a748786/attachment.diff