[Sugar-devel] Performance issues on XO 1 (Re: TamTamMini)

[Daniel Narvaez]

On 19 November 2013 07:08, Sebastian Silva <sebastian at fuentelibre.org>wrote:

> - What is slow exactly?
>
>  Initial startup, switch between activities, activity startup. Also
> probably redraw after widget damage e.g. the Frame appears. Then again it's
> hard to pinpoint exactly, just out of memory now.
>
>  - Why do you believe it's an issue with low level libraries (and which
> libraries)?
>
> I like to dogfood. I do all my work on a low end atom netbook. I have
> observed in my own use how applications ported to GTK3 have degraded
> performance (e.g. Evince, Gnumeric). I have come to expect this, really as
> I experienced the same thing when moving as a user from GTK1 to GTK2.
>

Thanks these are the kind of subjective impressions I was hoping to get my
questions. I have never seen Sugar on XO 1 myself :)


>  - Did you profile?
>
> Nope, but our images are still in beta and I'd be willing to profile and
> share the results by default. If it will help then we can have a metric.
>


I think there are a couple of things that would be worth profiling as a
first pass

* Free memory at boot.
* Clear kernel cache. Start HelloWord, measuring startup time. Start
HelloWorld again measuring startup time.

Ideally we would test these on old OS + gtk2, old OS + gtk3 (assuming the
images you are working with support gtk3 toolkit at all), new OS.

Note that I'm not saying you should do that work (though it would be great
of course :P). I was asking if you had done an profiling and you could
share it...

 Please don't assume people knows what they are talking about when they
> speak about performance, unless they back up their claims with profiling
> data, especially if they are just saying things are "lighter" and base a
> toolkit switch on that!
>
>
> I'm sure that they at least carefully measured the memory usage. On XO1
> this is critical with only 256mb ram. Also the OS by default has no swap.
>

I will not be sure until I see the numbers and metodology, measuring memory
usage on linux is *hard*.

The library size might have increased, but I doubt that's going to make
much of a difference even on 256mb because it will be shared by all the
processes.

I'm not saying there has not been regression. But I think there are a good
chances they might be fixable with a reasonable amount of resources.

 I know fairly well what changed between gtk2 and gtk3 and I have a very
> very hard time believing it introduced unfixable regressions. By
> design things should have improved, as far as I know. The problem is
> probably more that, as usual, the performance of the system developers
> works with has improved, thus with changes comes regressions that are not
> noticed. And the only way to counter that is to profile and fix the
> real issues...
>
> Understood. However it's a little out of my league, I admit. I tend to
> focus on serving low hanging fruit in a user friendly plate. This is why
> distributions interest me so much.
>

Of course, not many people like performance work.

My point is that if we target low end hardware and we use something which
normally used on much faster machines, then we can't hope it performs well
unless we at very least spend some time profiling and reporting issues.
Someone has to do that work.


>  I'm personally going to focus on newer hardware, but then isn't  XO
> 1 most of our user base currently? It seems we need to balance research and
> continued support here... Also note that the new hardware isn't going to be
> blazing fast either, the issue we find there are most likely very similar
> to the ones on the XO 1, just to a lesser scale. If we improve XO 1, other
> hardware will most likely improve too.
>
> Yes, only in newer hardware the impression that the Sugar user experience
> is not very good is not really related to performance, or at least, not
> primarily.
>

On my laptop I certainly can't notice any performance issue. But, for
example, on the XO 1.75 I think performance is infuriating. If you don't
see that anymore you must have spent too much time dogfooding :P


>  I think we need to get much better collectively at working on
> performance, it's a key aspect of the kind of hardware we are targeting and
> my feeling is that a lot of people don't like Sugar mostly because it's so
> slow...
>
> A platform is about the applications available to it. Sugar in my opinion
> has issues here as well. I tend to concur with Flavio that some aesthetics
> rework wouldn't hurt either. For what it's worth I always found interesting
> what the advertising firm that worked on Sugar published in their website:
> http://new.pentagram.com/2006/12/new-work-one-laptop-per-child/
>
> On the topic of aesthetics, it's interesting to see what even happens with
> adding a compositor (in metacity's gconf key) and changing some colors in
> style.py
> I recently noticed that in ancient versions (pre 0.82) the Journal items
> were separated with a thin line. This helped readability and gave the sense
> that each line was an object.
>
> Maybe I just went off topic (again) but now that we are sharing...
>

There would be a lot to discuss about UX but honestly until we figure out
how to work together I don't feel much like going on that topic. We are
unlikely to find common ground on something that complex if we can't even
sync on basic profiling (I'm referring to the rest of the thread, not to
this email).

And even if we had productive discussion we would not have resources to
implement the changes. IMO there are some resources but they are too
dispersed because we are unable to work together.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20131119/5a4efb68/attachment-0001.html>