[gcompris-devel] GCompris 8.5PRE for N900 - speed issues ahead

[Bruno Coudoin]

Le vendredi 01 janvier 2010 à 10:00 +0200, Terje Bergström a écrit :
> On 31.12.2009, at 20.34, Bruno Coudoin wrote:
> > I just commited an improvement of the performance of our svg item.
> 
> Thanks. I applied it to 8.5PRE3. I think I got it right.
> 
> > In this version we no more do pixmap search to find the bounds of an svg
> > item. We now use the librsvg rsvg_handle_get_position_sub () that
> > appeared in the library version 2.22.
> > GCompris seems more responsive now, especially the startup time.
> > Let me know if you see an improvement on the N910.
> 
> This made startup and other operations by a couple of seconds, but
> startup is still about 15-20 seconds, and delay between pressing quit
> and getting confirmation dialog dropped from 5 to 3 seconds. Still
> very slow.

I am glad to see we improved it a little bit but we still have room for
improvements.

> I profiled the process of clicking on quit button until dialog is open
> with oprofile. The output from opreport -l /opt/gcompris/bin/gcompris
> is attached. librsvg is not very prominent. This counts only the
> cycles inside each library, so it does not take into account
> situations where f.ex. librsvg would cause a lot of calls to
> libpixman. I'm trying to learn the tools so that I can load the call
> graph to a tool.

I never used oprifile, it's a good oportinity to start. I'll try to see
if we can save some more time. At a first sight, it seems we loose time
in creating the menu by doing many strcmp when we enter a menu entry.
Maybe there is something to improve there.


Looking at your report, it seems like we spend most of the time in
libpixman, probably to rescale all the images for the rendering. It
maybe mandatory to create a pre-rendered GCompris for a given screen
resolution. This would make it possible to run it on not so powerfull
devices.

By the way, happy new years everybody ;)

Bruo.