[Sugar-devel] opportunity for faster load time

Tomeu Vizoso tomeu at sugarlabs.org
Tue Jul 13 05:08:18 EDT 2010


On Tue, Jul 13, 2010 at 08:17, James Cameron <quozl at laptop.org> wrote:
> I've dug further on XO-1 with os300 and Sugar-0.84.  I think the delay
> you refer to is due to SVG rendering of the icons, since it correlates
> to icon complexity and file size.
>
> 1.  excluding _add_activity, using a standalone test program.
>
> import bundleregistry costs the most time, at about 1.5 seconds if
> pagecache is flushed, or 1.15 seconds if not.  The get_registry call
> was another 0.3 seconds on average.  The get_bundle_id,
> get_activity_version and is_bundle_favorite calls were insignificant.
>
> 2.  instrumenting favoritesview.py with time.time() calls.
>
> get_registry costs 0.16 seconds.  add_activity total costs 1.60
> seconds.  I confirm your finding.  connect was insignificant.
>
> 3.  instrumenting _add_activity to measure total time by favourite
> activity.  Result set below is the bundle id, the time measured, and
> ... the size of the icon file in bytes.
>
> vu.lux.olpc.Speak       0.077   800
> org.laptop.TamTamJam    0.120   5441
> org.laptop.TamTamEdit   0.062   2672
> org.laptop.MeasureActivity      0.059   1128
> org.laptop.Memorize     0.049   1666
> org.laptop.WebActivity  0.061   1414
> org.laptop.Oficina      0.071   2045
> com.garycmartin.Moon    0.104   1467
> org.laptop.HelpActivity 0.047   1360
> org.laptop.TamTamSynthLab       0.050   1091
> edu.mit.media.ScratchActivity   0.088   3677
> org.laptop.AcousticMeasure      0.073   4164
> org.laptop.RecordActivity       0.041   1056
> com.jotaro.ImplodeActivity      0.089   5544
> org.laptop.Pippy        0.072   1399
> vu.lux.olpc.Maze        0.033   791
> org.laptop.TamTamMini   0.073   2733
> org.laptop.Calculate    0.042   1366
> org.vpri.EtoysActivity  0.070   1442
> org.laptop.sugar.ReadActivity   0.056   1570
> org.laptop.TurtleArtActivity    0.102   3223
> org.laptop.Chat 0.049   913
> org.laptop.AbiWordActivity      0.054   1648
>
> Graphing the time against the file size suggested a correlation.
>
> Taking the outliers (TamTamJam and TurtleArtActivity at the high end
> vs Calculate and HelpActivity at the low end) and looking at these
> icons, I see that the complex icons correspond to longer load times.
>
> I suspect that much of the delay is the SVG rendering.
>
> 4.  digging deeper, instrumenting lower down, ActivityIcon is where the
> time is spent.  Isolating each part of __init__ the primary and varying
> cost is the call to _update.  All the other code in __init__ is under
> 0.02 seconds.  The call to _update ranges from 0.02 to 0.11 seconds.
>
> What _update is doing is to assign values to stroke_color and
> fill_color ... which in CanvasIcon are properties that activate
> methods such as set_stroke_color and set_fill_color.
>
> Splitting the time taken for each of these lines of _update show very
> small times, and they don't add up to the time over the _update call.
>
> Therefore something additional is happening between the end of the
> ActivityIcon._refresh and ActivityIcon._update calls in
> ActivityIcon.__init__.
>
> My guess is that it is the deferred rendering of the icon by
> hippocanvas.  But I don't know how to prove it.

This is how I instrumented a hippo.Canvas for measuring how long it
takes rendering. For s.g.i.Icon would be similar but the methods to
override are the ones starting with do_paint_*.

class MyCanvas(hippo.Canvas):
    __gtype_name__ = 'MyCanvas'

    def __init__(self):
        hippo.Canvas.__init__(self)

    def do_expose_event(self, event):
        import time
        t = time.time()
        hippo.Canvas.do_expose_event(self, event)
        logging.debug('listview expose event: %r' % (time.time() - t))

Regards,

Tomeu

> I'm also curious about the size of the icon being set *after*
> ActivityIcon instance is returned.  If rendering really is happening in
> __init__, then what resolution is it happening at, and is it redone when
> the size of the icon is constrained immediately after?
>
> --
> James Cameron
> http://quozl.linux.org.au/
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>


More information about the Sugar-devel mailing list