Bzr's startup time

[John Arbash Meinel]

Aaron Bentley wrote:
> Martin Pool wrote:
>>> On 26 Jun 2006, Matthieu Moy <Matthieu.Moy at imag.fr> wrote:
>>>> 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.
> 
> I'm still quite fond of the approach I used in Bugs Everywhere, in which
> each command corresponds to a module with the same name.  In BE, when
> you run 'be set-root', it finds a file named 'becommands/set_root.py'
> and imports it.
> 
> I believe we could easily integrate that approach with our current
> structure, except that we would need to change alias handling.  Keeping
> aliases in the Command object would mean they would not be loaded when
> we needed them, so we would need to separate the alias list from the
> Command objects.
> 
> Aaron

Yeah. At this point you need some kind of registry (at least for
aliases). And we should think how this would work for plugins as well.

We could just have a list of lazy imports/registrations in commands.py
or builtins.py.

I think the registration function could take a list, rather than calling
it N times for all the different commands, just call it 1 time with a
big table.

We can still load the class, and figure out what its arguments are, etc,
when we are parsing the command line arguments.
So all it would really mean is instead of looking at globals() and
searching for things that start with cmd_*, we could put a call to
'register_builtin_commands()' at the bottom of builtins.py, and slowly
migrate commands out of that file into children files. Say in
bzrlib/commands/foo.py
Or if we prefer:
bzrlib/commands/cmd_foo.py

The only real change is to switch from a 'get these implicitly', to
calling a registration function. I think the number of new commands has
settled down, so it is okay to start being more explicit about it.
(Plugins already have to register their commands).

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060626/85a440ac/attachment.pgp