OLPC upgrades

Benjamin M. Schwartz bmschwar at fas.harvard.edu
Tue Feb 3 17:46:45 EST 2009

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.

> 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!

> 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

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.

- --Ben
Version: GnuPG v2.0.9 (GNU/Linux)


More information about the Devel mailing list