OLPC upgrades

[Tiago Marques]

On Tue, Feb 3, 2009 at 10:46 PM, Benjamin M. Schwartz <
bmschwar at fas.harvard.edu> 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.


It's a fact. I have installed xfce in NAND together with Sugar and I'm
running Opera with four tabs(one with the heavy gmail) and terminal - using
136MiB and no swap. Opera seems to leak memory though, it was only of *
120MiB* when it had the four tabs oppened and not much usage, the same test
scenario as with browse. Browse was a lot better at maintaining a more
constant footprint, though.
Adding a PDF in Acrobat(evince doesn't install easily) added this to 157MiB
and 40MiB of swap.

Sugar, terminal open 111MiB, add a browse and it climbs to *165MiB* with
gmail open. Add a PDF and it gets to 181MiB and 6 of swap memory in use.

My biggest problem with python has always been memory usage, not speed. In
the XO, memory usage is far more important than speed(although graphics
rendering is quite slow), IMHO, especially with XOs being deployed without
swap.
I have run the Pardus distro in a few computers, it was quite nice but had
two or three apps(like network applet) written in python. Memory usage was
60-100% more than most, if not all, distros that I could find, upon booting
just the desktop, mostly for these small apps that could very well be
written in C.

If even Opera manages a lower memory footprint than browse(with more pages
open), something can be done to improve browse - Opera is a more complex
than browse will ever be - or need to be. At least to reduce the overhead of
opening up one instance. Opening two didn't seem to bring much hurdle(which
I find remarkable) but the initial overhead was too high.

Sugar terminal ~8s to load, Xfce Terminal ~2s, and one was spent mostly
rendering the window, after it loaded.


>
> > 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
> 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.
>
Would that be welcome?
Best regards,
                          Tiago Marques


> - --Ben
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
>
> iEYEARECAAYFAkmIyVUACgkQUJT6e6HFtqSgFgCfdmmKz5qoy7AdDw7XVq1lh0/t
> NmMAnij1vpH7oGOa/9h2z/fvrlP745gs
> =VpmM
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20090207/79d47127/attachment.html>