Reducing Sugar's memory usage

One of the biggest performance problems of Sugar is caused because we use a lot of python modules. This is worst in python than in C or other languages because the bindings for these libraries need to initialize a big bunch of stuff when they are loaded and that takes quite a bit of cpu time and of memory that never gets released.

The visible effects of this are slow startup of activities and occasional system crashes on systems with little memory and no swap as the OLPC's XO.

In the past weeks I have been working on improvements to PyBank so it can run Sugar. PyBank will allow us to use any library based in GObject without having to load a bindings module. I have measured a reduction of memory usage of more than 4MB (from a total of 22MB) for the shell, though I haven't managed yet to run it with all its functionality due to missing pieces in gobject-introspection and PyBank. Each other process that previously used pygtk (almost every base activity) will show a similar reduction in 4-5MB.

I have big hopes for this because we'll get these additional benefits:

- we'll be able to run more activities simultaneously,

- we'll be able to run on systems with less memory,

- we'll be able trade some of the memory savings for compositing some windows so less redraws will happen, leading to a more responsive UI,

- the shell and activities will start much faster,

- by moving the sugar toolkit from python to a GObject library with introspection support, we can completely drop several python modules thus reducing further the footprint. Also activity authors will be able to use the toolkit from languages other than python.

Now, the bad news is that though we have made great advances in this plan, we have only a few months until the next release. My current estimation is that I would need most of that time in order to bring the needed infrastructure to the needed level of maturity, and even then we'll face most probably issues regarding the packaging of the various pieces in all the distros where we want Sugar to be well supported.

So right now my opinion is that we should put this effort to rest for a few months while the base components mature and get packaged for distros and then come back to it after 0.86 is released. Hopefully by 0.88 we'll have a much leaner and faster Sugar leading to more learning for children like this:



If someone wants to hack further on this, you will need to checkout and install the following modules in sugar-jhbuild:

http://git.gnome.org/cgit/glib
http://git.gnome.org/cgit/pygobject/
http://git.gnome.org/cgit/gobject-introspection/
http://git.gnome.org/cgit/gir-repository/
http://git.sugarlabs.org/projects/pybank/repos/mainline
http://git.sugarlabs.org/projects/sugar/repos/sugar-pybank
http://git.sugarlabs.org/projects/sugar-toolkit/repos/sugar-toolkit-pybank

Then you will need to convert the sources in sugar-pybank and sugar-toolkit-pybank with the sed script in sugar-pybank called pybank-convert.sh .

Johan Dahlin has been of great help during this time, his deep knowledge of pygobject has been invaluable. Also go thanks to Simon Schampijer, Marco Pesenti Gritti and Bernie Innocenti for their moral support. We'll get there, eventually! ;)