On Fri, 2008-02-08 at 14:44 +0100, Tomeu Vizoso wrote:
> On Fri, 2008-02-08 at 13:41 +0100, Tomeu Vizoso wrote:
> > On Thu, 2008-02-07 at 16:46 +, Simon McVittie wrote:
> > > A better solution would be for Rainbow to avoid SessionBus()
> entirely,
> > > and instead use an instance of the superc
On Fri, 2008-02-08 at 13:41 +0100, Tomeu Vizoso wrote:
> On Thu, 2008-02-07 at 16:46 +, Simon McVittie wrote:
> > A better solution would be for Rainbow to avoid SessionBus() entirely,
> > and instead use an instance of the superclass, dbus.bus.BusConnection. This
> > does not have the weird c
On Thu, 2008-02-07 at 16:46 +, Simon McVittie wrote:
> A better solution would be for Rainbow to avoid SessionBus() entirely,
> and instead use an instance of the superclass, dbus.bus.BusConnection. This
> does not have the weird caching behaviour at all (one call to the
> constructor = one ins
Hi Jukka,
On Feb 6, 2008, at 11:13 AM, Klaus Weidner wrote:
> 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
On Feb 7, 2008, at 3:06 PM, Frank Ch. Eigler wrote:
> To what extent could prelinking, which should improve this aspect,
> be used on OLPC?
It was tested and found to have no measurable performance impact.
--
Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org
___
[EMAIL PROTECTED] writes:
> [...] I can't comment on python modules, but I've seen similar
> issue on shared libraries with firewall proxies that did a fork for
> each connection. [...] if you can get the linking and
> initialization step down to once per boot it will bee a huge win.
To what ex
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 06 Feb 2008 at 23:06:19 -0500, Michael Stone wrote:
> Next, according to dbus-python's dbus/_dbus.py, the SessionBus returned
> when you call SessionBus() is cached in
>
> Bus._shared_instances[BUS_SESSION]
This is not an API guarantee; ne
On Wed, 6 Feb 2008, Benjamin M. Schwartz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> 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
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 co
On Wed, 2008-02-06 at 09:59 -0500, Benjamin M. Schwartz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Tomeu Vizoso wrote:
> > If I understand correctly how that fork() would work, what we would be
> > saving in that case is the reading of modules, but the python code at
> > the modu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 06 Feb 2008 at 10:13:23 -0600, Klaus Weidner wrote:
> Would it be feasible/helpful to use the "uncore" approach used by Emacs?
[...]
> Of course, any initialization done initially must not depend on external
> state, so for example any connecti
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 fo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tomeu Vizoso wrote:
> If I understand correctly how that fork() would work, what we would be
> saving in that case is the reading of modules, but the python code at
> the module scope would need to be executed anyway.
I am no expert, but, without evid
On Wed, 2008-02-06 at 09:31 -0500, Benjamin M. Schwartz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> 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_ startu
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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
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
17 matches
Mail list logo
