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

[Gonzalo Odiard]

Concrete data and actionable tasks would help.
Please share your profiling when you have it.

Gonzalo


On Tue, Nov 19, 2013 at 3:08 AM, Sebastian Silva
<sebastian at fuentelibre.org>wrote:

>  Hi Daniel,
>
> Thanks for your thoughtful answer. I reply inline to the issues raised.
>
> El 18/11/13 08:30, Daniel Narvaez escribió:
>
> Hi Sebastian,
>
>  It would be really useful if you could give some more informations on
> the performance issues you have been seeing
>
>  - 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.
>
> - 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.
>
>
>  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 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.
>
>
>  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.
>
>
>  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...
>
>
>  --
> Daniel Narvaez
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20131119/39e1eeab/attachment-0001.html>