[gcompris-devel] Performance issues

[Terje Bergström]

On Wednesday 26 September 2007 21:30:34 Yavor Doganov wrote:
> I'm not sure if it is at all possible to make analogy when it comes to
> CPU frequencies on different architectures.

Of course not, but it's some indication. OMAP does in one cycle more than 
desktop processors, and N800 has somewhat less stuff going in background than 
normal Ubuntu installations.

> FWIW, I do experience everything that you describe, but it never
> annoyed me.  On these machines, GCompris is completely usable
> application compared to OpenOffice.org, Firefox or Evolution.

Performance and feeling of responsiveness is always subjective. I find it very 
annoying to click on something and not get any indication that something is 
happening. If I don't get feedback, I tend to click on buttons several times 
to make sure the click "went through". I do know that software with similar 
and higher complexity than gcompris is able to run very smoothly in N800, so 
there is room for improvement.

On the brighter side, compiling with optimizations helped, i.e. it's much more 
responsive. I suspect something uses a lot of floating point and having them 
software emulated did not help a lot. Now hardware floating point is enabled. 
I seem to have lost the paintings puzzle which I have used previously for 
performance testing, but in the tangram puzzle the pieces get dragged around 
in real time.

There is still a long lag between clicking on an activity in menu and getting 
it started, or clicking on "home" in activity and getting back to menu, or 
clicking on basically anything in the bottom row and getting a response. I'll 
try to see what could be the problem. Any ideas are welcome. Perhaps the 
touch screen is not treated the same way as mouse clicks or something like 
that.

Out of curiosity, I installed oprofile and ran a short test. If I did 
everything correctly, most of the time in gcompris is spent actually in 
gnomecanvas (more than 10000 for libgnomecanvas vs. 24 samples for gcompris). 
This of course leads to thinking that a faster canvas could lead to 
significant performance boost. Then the question becomes that is the way 
gcompris uses canvas somehow non-optimal or is gnomecanvas just plain slow.

Best regards,
Terje