[sugar] python activities startup
Wed Feb 6 23:06:19 EST 2008
> 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 , 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
However, please let us know if your measurements support or refute
"Wingo's hypothesis" that we will see essentially zero net memory
> 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
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
(where BUS_SESSION is a constant from _dbus_bindings).
Consequently, if you make a new BusConnection and save it as
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
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.
More information about the Sugar-devel