python activities startup

Klaus Weidner kweidner at
Wed Feb 6 11:13:23 EST 2008

On Wed, Feb 06, 2008 at 09:31:02AM -0500, Benjamin M. Schwartz wrote:
> Tomeu Vizoso wrote:
> > By the data in #5228, looks like more than 50% of time is spent
> > importing modules. dbus, telepathy and pygtk make for more than 30% of
> > _total_ startup time.
> There has been much talk about fork()ing the python interpreter for each
> activity instead of starting a new interpreter.  AFAIK, the python interpreter
> only does nontrivial work the first time a module is imported in each
> interpreter.  By this logic, if we use a forked interpreter and import these
> modules at the root, it seems that the import will only have to happen once at
> Sugar startup, rather than once for each Activity.
> I would appreciate a comment on this from someone who knows more about the
> relevant issues, like the interaction of CoW memory and python modules.

(Disclaimer: I know nothing at all about Python internals)

Would it be feasible/helpful to use the "uncore" approach used by Emacs?

- launch Python interpreter, load and initialize modules

- force the interpreter to dump core

- convert the core file to an executable file that has all the modules
  loaded and initialized already

- activities use this preloaded executable instead of the plain python

Of course, any initialization done initially must not depend on external
state, so for example any connections to the X server or other network
connections would need to be delayed or reopened when running the final
application. If that's where most of the time or effort is spent, this
approach would not be helpful.


More information about the Devel mailing list