Plasma::Svg and performance

[Marco Martin]

On Wednesday 15 October 2008, Marco Martin wrote:
> On Wednesday 15 October 2008, Aaron J. Seigo wrote:
> > hi ..
> >
> > doing some profiling with valgrind/massif, i noticed that a large amount
> > of start up processing and memory usage is spent in parsing SVGs.
> > surprise! ;)
> >
> > i introduced a KPixmapCache for on-disk caching to help prevent the need
> > to render from the source SVG over and over.
> >
> > i was able to squeeze ~1MB of RAM usage out by doing that. but we can be
> > even better ....
> >
> > right now what is kicking us in the teeth is accessing embedded hints in
> > the SVG file. turns out they are SUCH a great idea after all ;) at least
> > not when we don't cache them, resulting in unecessary parsing of the SVG.
> >
> > in particular, those include:
>
> will try the patch, i'm willing to do something aout it...
> i was thinking about a QHash of rects keps by Svg, so haselement is a check
> for the existence of the key elementRect fetches the value and elementsize
> its size
> the first time calles well, still suck, but inevitable...
> all the cache kiled on theme changed annd when the svg changes on disk how
> behave? hmmm...

ok, this patch is the idea, it seems to work, still has two problems dunno how 
relevant:
-when checking for element existence it computes the rect, a bit of a waste, 
but this way don't have to keep two separate caches for rect and for existence
-when checking for a non existent element it saves nothing because still 
invokes the renderer every time.. perhaps saving also a list of queried not 
existent elements? (maybe imited to a fixed number of elements say 100 to not 
make it grow forever)

Cheers,
Marco Martin


-------------- next part --------------
A non-text attachment was scrubbed...
Name: svgcacheRects.diff
Type: text/x-patch
Size: 3053 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20081015/9cbf33ec/attachment.diff