Benjamin M. Schwartz
bmschwar at fas.harvard.edu
Tue Feb 3 17:46:45 EST 2009
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Devel