Rendering of reStructured text is not possible, please install Docutils.
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).
