There was also the issue that Mike Heam brought up about the linking
overhead of importing _gtk.so in particular. Here I must profess that
I am largely ignorant of the issues, but I'll speculate anyway.
Perhaps just splitting up _gtk.so into separate modules would be
helpful, particularly if there are really different kinds of
functionality so that some might never be needed by an application
(just switching to lazy imports only stretches out the performance
problem, and I'm not sure that's a good solution here). But even
then, the memory overhead is quite substantial (8Mb?) so his
suggestion to fork an already-gtk-initialized Python process might be
the only way to address both issues reliably. (My own intuition is
that PyGTK is representing every GTK object with a corresponding
Python object, which causes a duplication that may not be necessary,
but even if that is true it's part of the basic architecture of PyGTK
so it's not going to be easy to change).
That's basically what maemo-launcher does... for more details:
http://maemo.org/lxr/source/maemo-launcher/README
I tend to think we should do both. Write something similar for python
but also improve gtk/pygtk startup performance (so that at some point
the hack will not be necessary anymore).
Marco
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
