These tests were run on a Dual Pentium 4 Xeon 2.4GHz, with 3GB of RAM, and a single 7400 RPM 80GB hard drive (circa 2003). 'bzr status' improvements ========================= Bzr version 0.15 introduces a new disk format for managing working trees. Older versions of bzr used XML files to track what files were versioned, this served us fairly well, but XML is slow to parse, and the file content itself did not lend itself to partial processing. We also cleaned up lots of our code paths with this new format. So that when you run '``bzr status``' it is able to find and ignore unchanged paths very quickly. So how much of an improvement is it: .. image:: attachment:bzr-status-bzr-0.15.png .. image:: attachment:bzr-status-lp-0.15.png .. image:: attachment:bzr-status-kernel-0.15.png .. image:: attachment:bzr-status-moz-0.15.png The marks on each bar indicate 1 standard deviation. The results for versions 0.9, 0.10, 0.11, 0.12, and 0.13 are grouped into a single bar, because there was only a minimal difference between them. The biggest wins are naturally versus bzr 0.8. We have been continually improving with each release (not all releases affected ``bzr status`` specifically). In a smaller tree (671 entries), ``bzr status`` for a single file is about 2x faster and ``bzr status README`` is about 2.5x faster. The biggest win, though, is as the tree size starts to scale up. For a tree with 4600 entries, the difference is 3.1x and 6.5x. For the Linux Kernel (approx 22,450 entries), the difference is 2.2x and 13.9x. For a simple Mozilla tree conversion (approx 54,000 entries) it is 2.8x and 14.4x. A more fair comparison is against our previous release, where we are from 1.2x to 1.7x faster for the whole tree, and 1.3x to 9x faster. In general, the larger the tree, the bigger the benefit. You can see that we are doing significantly better in 0.15 versus all previous releases. We know of some more improvements (especially for the single-file case). But we are very happy with the current work. (One possibility is to rewrite the core loops in C, and another is to bisect the status file when we only need the state of a couple entries). Because this is a new format, you need to do a bit of work to get the improvement. Specifically, you need to run ``bzr upgrade`` in an existing tree. We did make the new format the default, so doing ``bzr branch http://other/branch`` will give you the upgraded working tree format locally. (Note that this does not affect the Branch, just the working tree. So any version of bzr since 0.8 read and write to the Branch, they just can't update the working tree).