OLPC upgrades

[david at lang.hm]

On Tue, 3 Feb 2009, Benjamin M. Schwartz wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> david at lang.hm wrote:
>> the fact that KDE and GNOME (both desktops that are considered pigs on
>> normal machines) make a XO laptop seem snappy by comparison to Sugar (as
>> of December) means that there is a significant problem with Sugar.
>
> I'm not happy to simply take this as "fact".  It's either a measurement or
> an opinion.

Ok, what tools can I use to satisfy you of this 'opinion' that 
applications start faster on either KDE or GNOME than on Sugar on the same 
hardware.

by the way, you are the first person I have heard dispute this.

>> when
>> people ask about how to fix things, the answers that keep coming back
>> all appear to be python related.
>
> The whole system is in Python!  Everything is going to be python-related!

no, it's only python related if implementations that don't use python 
are significantly faster. and they are.

>> so it's not FUD to say that the
>> dependance on Python is hurting performance.
>
> It's not "FUD", but it's not exactly substantiated.  We have some
> understanding of where we are spending our cycles, and it's not as simple
> as "in the python interpreter".  For example, measurements of activity
> startup time indicate that we're spending a lot of time in SVG rendering
> and Cairo.  This isn't too surprising, since Sugar uses SVGs much more
> intensively than most desktop environments, and often renders many
> different versions of the same icon for the purposes of recolorization or
> animation.
>
> There are certainly many improvements we could make to perceived speed.
> Some, like fixing upstream modules (e.g. dbus-python) not to do any
> computation at import time, are "python-related", though they have little
> to do with the language itself.  Some, like switching to a better
> filesystem or testing LZO support in JFFS2, are entirely separate.  Many,
> like rewriting the Journal GUI to minimize redrawing of widgets and enable
> smarter scrolling, are large projects.
>
> Blaming Python for our user-experience speed problems is not scientific,
> and it's not helpful.  Have you found some critical piece of code that you
> can rewrite in C for speed?  We'd love that.

let's start with the application startup time. the last I heard the reason 
why it take a noticable amount of time to startup a trivial app like the 
terminal window is due to all the python module initialization.

unless this has changed in something newer than 8.2, it's still several 
seconds to start the terminal window compared to significantly sub-second 
to starup xterm (to give a trivial enough example to be easily measured)

similar differences show up with more complex apps like browsers.

it doesn't matter if it's 'python related' by your definition, or only 
becouse using python is forcing you to use the associated python libraries 
that do stupid things at startup time. either way it's the python 
implementation that is the problem.

David Lang