[sugar] Performance

[Marco Pesenti Gritti]

Greg Smith wrote:
> Hi Michael,
>
> 7395 has a release contract (see http://dev.laptop.org/report/18)
>
> I believe that we will lose a lot of other work too if we don't fix it.
>
> What do we need to do to get this assigned and resolved?
>
> I upped the priority to Blocker (will negotiate from there as needed :-).
>
> All,
>
> Looking past 8.2.0 (AKA last call for quick wins :-).
>
> On the question of what are they doing, they have a journal. I don't 
> know how we can get it or what we would do with it but the journal is a 
> complete record.
>
> I have two 656 XOs on my desk, both of which are painfully slow. One is 
> the XO I got w/G1G1 in December. Its mostly unusable. The other is about 
> 85% full on the NAND (I tried to fill it when testing recent issue). Its 
> very slow too but a little better. I have those journals if you want them.
>   

Yeah, please make them available.

> Here are my impressions:
> - very slow to launch activity
> - long wait for frame to appear and disappear, compounded by cursor 
> twitchiness
> - impossible to open anything from the journal which looks like slowness
> - slow to save
>
> Its a matter of seconds in each case (e.g. 5 seconds to save  (keep) 
> simple animation from cartoon builder. I think the challenge is that 
> every click costs 5 seconds or more which makes for a very frustrating 
> experience
>
> I think we can test and verify this area if we have something to try. 
> Does anyone have examples of changes in 708 that may be related to the 
> above?
>
> Can someone help me layout a strategy for improving this on the 9.1.0 page?
> http://wiki.laptop.org/go/9.1.0#Performance_and_Reliability
>
> Performance is not one of Ben's top 6 but I think it deserves a similar 
> scoping and definition so we can prioritize it appropriately.
>   

I think there are two main areas that we can attack:

1 General UI sluggishness.

Without going too deep into the stack, I think there is a lot of space 
for improvement even in the python code. Michael mentioned icon cache 
and mesh view layout, both areas of the code that didn't get any love 
for a while and where I'm convinced we can make big/quick progresses. 
I'm planning to spend a lot of my time on this in the next release cycle.

2 Datastore performance.

I'd expect improving jffs2 performance would be a big win there. The UI 
can probably be smarter in the way it uses the datastore too Finally we 
can try to improve at the datastore level, but there we clash with the 
rewrite plans. I think we should find an agreement on the datastore 
design and just try and get it done for 9.1.0, there are two many things 
blocking on it.

We need to allocate time and focus to do some good profiling and then 
attack the problems we find. That's why I'm advocating for the next  
Sugar release cycle to be largely about perfomance improvements, bug 
fixes and code refactoring, with the possible exception of the datastore 
rewrite.

Marco