[sugar] python activities startup

[Tomeu Vizoso]

On Wed, 2008-02-06 at 15:20 +0100, Ryan Pavlik wrote:
> Tomeu Vizoso wrote:
> > Hi,
> >
> > as we all know, activities that use the python API (most of them) start
> > up very slow in the XO, a trivial one launching in 7 seconds.
> >
> > http://dev.laptop.org/ticket/5228
> >
> > I don't know yet if performance work will land in update.2 or in
> > update.3, but now may be a good moment to summarize what we know and see
> > which are our options.
> >
> > 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.
> >
> > In that ticket is attached a file that lists the 161 modules imported at
> > startup. I doubt most of those modules are actually used during startup,
> > and many won't be used neither during the activity lifetime, they are
> > just imported because one module we actually use *may* need it at some
> > point.
> >
> > It's clear that we would prefer to not pay this price upfront at
> > startup, but rather that the needed initializations happened during
> > runtime as (if) needed.
> >
> > I would like to take the chance to ask to Guido what's his opinion on
> > this, as I'm sure this has been discussed in the python community at
> > some point. How could we move all these initializations from import time
> > to use time?
> >
> > I see the following options:
> >
> > - Reduce the number of things that are done at startup. We probably
> > could write to the datastore, initialize sharing and creating the D-Bus
> > service at a later point after startup. These changes look to me as
> > quite invasive and somewhat risky. The benefit from the user point of
> > view is not clear, as we would like those things to happen as soon as
> > possible after the activity window has been brought up.
> >
> > - Modify the modules that do significant initializations at import time
> > so that code is executed lazily as needed. Those modules will be inside
> > python itself, dbus, pygtk, telepathy, sugar, etc. The drawback of this
> > approach is that we'll need to maintain forks for some time.
> >
> > - Hack the import logic in python so that the module-level code is
> > executed only when some function or method from that module is called or
> > a variable is set. I'm not sure if this is possible by just using the
> > existing hooks or if we would need to patch python. In case this brings
> > some incompatibilities, we could activate this "fast mode" through some
> > flag.
> >
> > I wonder too if python 2.6 and 3.0 will bring some improvement in these
> > areas?
> >
> > Thanks,
> >
> > Tomeu
> >
> >
> > _______________________________________________
> > Sugar mailing list
> > Sugar at lists.laptop.org
> > http://lists.laptop.org/listinfo/sugar
> >
> >   
> Though it's not very elegant, you can import anywhere and I believe the 
> import is then available everywhere (within that module).  You might be 
> able to just move the import statements to right before they are needed 
> - I believe multiple imports are ignored, so if imported functions are 
> needed in multiple places, import in each of those (or the first to 
> execute if it is deterministic).  Not really pretty, but it might do the 
> trick.... I think...

This would help only for the imports in sugar modules that are not
actually used during startup. Sadly, none of the modules that appear in
the profiles as significant fall into this category.

Tomeu