ginormous performance issue

[Marco Martin]

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 :)