[sugar] python activities startup

Michael Stone michael
Wed Feb 6 23:06:19 EST 2008


Tomeu,

> I have hacked the rainbow service in the following way:

Please publish your code so that we can have a look at it.

> - rainbow preimports pygtk, telepathy, dbus and some slow sugar modules.
> - after cloning, reconnect to X.
> - instead of execvpe sugar-activity, directly execute the code.
> 
> Python activities have the expected speedup, from 7 seconds to 3.

What is costing us the remaining 3 seconds? 

> Haven't measured the memory usage improvement yet.

If python dirties every page when it updates refcounts, as is asserted
in the 'lessons' section of Andy Wingo's memory-profiling post [1], then
it seems that our strategies for improving memory usage in
Python-based activities are to change this behavior in our python
interpreter or to reduce the number of pages which are mapped by our
python-based activities.

However, please let us know if your measurements support or refute
"Wingo's hypothesis" that we will see essentially zero net memory
savings.

> The visible problems right now are that the D-Bus connection to the
> session bus is stale (how can we reconnect?) and that the activity uses
> the default gtk theme and not the Sugar one. These two should be quite
> easily solvable.

The gtk theme is controlled by the setting of the 'GTK2_RC_FILES'
environment variable. Setting

  GTK2_RC_FILES=/usr/share/sugar/data/sugar-xo.gtkrc

before importing gtk should do the trick.

Next, according to dbus-python's dbus/_dbus.py, the SessionBus returned
when you call SessionBus() is cached in 

  Bus._shared_instances[BUS_SESSION]

(where BUS_SESSION is a constant from _dbus_bindings). 

Consequently, if you make a new BusConnection and save it as

  Bus._shared_instances[BUS_SESSION]

post-fork(), you should be good to go.  

> I think Michael, Scott and Chris played in the past with this idea. What
> was your conclusion? Anybody saw any flaw with this approach? Security
> implications?

The conclusion was that it was unlikely to result in memory savings.
Since we really wanted memory savings, nobody tried it out. Thanks for
stepping up to the plate - now let's see if we can make it shippable.

Best,

Michael

[1]: http://wingolog.org/archives/2007/11/27/reducing-the-footprint-of-python-applications



More information about the Sugar-devel mailing list