Over the last few weeks, I’ve been converting a snapshot of OpenOffice.org to the various candidate formats and using bzr-usertest to get an overview of performance on common operations. OOo is 75K files and 260K revisions – at least an order of magnitude bigger than most other “huge” projects (like Emacs), so it’s an ideal stress test.
The results for the 2a benchmark can be found here. For this particular run, the baseline is a conversion of OOo to packs I did last year. It’s not strictly an apples-to-apples comparison because the OOo snapshot I used for generating the 2a repository is more recent but it’s good enough to highlight where we’ve progressed and where we still have some work to do.
All together, the report compares 3 scenarios:
- bzr.dev r4487 on last year’s OOo pack repo
- bzr.dev r4487 on this year’s OOo 2a repo
- bzr.dev r4476 + some proposed patches on the 2a repo above.
Technically, there are two key things that still need tuning:
- selective commit – my proposed patch is one option but it’s not fully cooked and Robert is working on a better one
- full inventory loading – this is impacting branch & send times. (History:listAll isn’t a common use case but it’s included in this report because it’s indicative of this problem).
I believe John has some ideas on how this latter issue can be addressed though it may not be at the top of his queue yet.
In a nutshell, 2a with the latest bzr.dev is looking pretty good:
- status, diff and commit typically take a second or two
- recent history commands take 0.2 seconds
- full history log takes around a minute
So while we still have room for improvement and work to do, the combination of our new repository format and our latest code means that Bazaar’s scalability should no longer be an issue for projects wanting to migrate to it.