Bzr's startup time

Martin Pool mbp at canonical.com
Mon Jun 26 09:50:34 BST 2006


On 26 Jun 2006, Matthieu Moy <Matthieu.Moy at imag.fr> wrote:

> I think the large number of python imports at the beginning of
> builtins.py is also a problem.

Well, one instance of a problem that we generally tend to load
everything.

> For example, to run "bzr version", I need to load builtins.py which in
> turn will load many thing in bzrlib to just issue a trivial message.
> Similarly, some local operations (bzr ignore, bzr add) will need to
> import Branch.
> 
> It would probably be wise to split the command functions in
> builtins.py into a trivial function doing only the argument parsing,
> and calling a function in another file, which in turn would do the
> correct imports and perform the actual job.

This is the kind of approach we want regardless of load time - splitting
the details of command line parsing from the high level operation
itself.  It makes it more reusable for say people writing a GUI.  Some
commands do this more consistently than others; we should sometime do a
pass through and shrink or separate the command functions.

This still leaves the question of how the implementation gets loaded: it
can be either from inside the method or through a demandload.

Also we need to look at what must be loaded for typical operations on a
local working tree or a remote branch or other common cases -- both code
and IO.  For example the current workingtree format tends to take a
relatively long while to load (through celementtree) and to do more IO
to load the state than we would like.  So just fixing imports is not
enough.

I originally used xml for some representations as a safe, neutral
decision and to leave options open for the future as far as sharing data
with a C implementation -- essentially a way to skip a relatively
uninteresting area of the problem space.  I think that was an OK interim
solution, but now when we start to look at the costs it seems that we
can be substantially faster in operation and startup (even despite the
very nice cElementTree library.)

-- 
Martin




More information about the bazaar mailing list