selftest performance: landing our code faster and developing quicker.

John Arbash Meinel john at
Tue Sep 1 17:45:09 BST 2009

Hash: SHA1

> We have a number of things contributing to this:
>  - some of our test parameterisation runs many permutations we expect to
>    fail. we could fairly cheaply just not create those.
>  - we have some tests that need to do expensive things
>  - some of our test support code is slower than it needs to be.
>  - We run our core code several hundred thousand times, and our UI code 
>    only once or twice for some tests.
>  - IO is slow.

One thing that could benefit here, is making it easier to get access to
memory-only actions.

Specifically, we have "TestCaseWithMemoryTransport", but it is not easy
to actually get what you need. Because the direct subclass is
TestCaseWithTransport, and that is the base class for all of the
TestCaseWithBzrdir/Branch/Repository/etc classes.

And neither self.make_branch_builder() nor self.make_branch_and_tree()
are able to create something in memory. (They both take a relpath, which
must be a relative path, and never something like 'memory:///')

I agree that we have a few tests that set up a lot of state, just to
find out that it doesn't actually allow what we want to test.

We could also improve things by just making "initialize()" return a
write-locked object. Rather than taking out a write lock, building the
thing, unlocking it, and then returning it so that we have to lock it again.

I don't know the overhead on Linux. I *do* know the overhead of locking
and unlocking all the time on Windows. Though this is also compounded by
the fact that we don't have a way to hold the real repository write lock
across multiple commits.

For *my* purposes, having BranchBuilder backed by MemoryTransport would
work for 90+% of what I'm trying to test.

Another possibility is the old "Factory" discussion. I think a lot of
tests could use pre-canned data. Which means it would only need to be
set up once, and then from then on it could be used in read-only fashion.
This would also have the advantage that Jelmer's work to create a
testing subset for foreign branches. You could implement similar canned
data for a 'git' or 'svn' repository, and then the rest of the API can
be tested against that canned data. Without having to worry about
conforming to all of the exact 'commit' based semantics.

Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla -


More information about the bazaar mailing list