RFC: startup time - again

[Martin Pool]

On Tue, Sep 9, 2008 at 8:50 PM, Andrew Bennetts <andrew at canonical.com> wrote:
> Robert Collins wrote:
>> So, Martin and I just had an interesting chat. We were talking about
>> startup time and lazy_import etc.
>>
>> startup time, such as 'bzr rocks' isn't a very useful metric for 'how
>> slow is bzr to get going'. Much more useful is running a command with
>> little work, and the same command with lots of work.

We also talked about a couple of other things I'll mention briefly:

A daemon and C client, which has been prototyped by John and others.
It will take some work to make it really robust, and only reduces the
initial-startup time, not the scaling factor.  (Mind you most of
Robert's mail is about the startup time too.)

Having the entry point in C rather than in Python, and eventually
transitioning to running some commands without a Python interpreter at
all.  It's nontrivial to get there, if you want to keep all our
extension points for plugins, transports, formats, etc.  And just
starting Python is not the largest issue.

> I think an error registry is a good idea.  Currently, it appears to take 14.6ms
> to import bzrlib.errors on my laptop, which is pretty huge!

I would say also we should be a bit smarter about when we add a new
error class; I've mentioned it in reviews but should probably put up a
coding standard patch.

Adding a new class is a good way to let calling code (in bzrlib or
elsewhere) distinguish that particular error case and catch it.

If the exception indicates a code bug and is not intended to be
caught, it doesn't need a specific class.  AssertionError, ValueError,
etc, is enough.

If the error is different only in that it gives a different message to
the user, it also doesn't need a new class.

Cases that might need to be reported to either the user or calling
code need some thought; sometimes adding a new class is right but it
may be more complex.

Adding one more class won't kill us, but as they say in the Pentagon,
"a billion here, a billion there, pretty soon you've spent a lot of
money."

-- 
Martin <http://launchpad.net/~mbp/>