System call analysis report

[Robert Collins]

On Fri, 2007-05-11 at 09:11 -0400, John Yates wrote:
> How hard (and how useful?) would it be to have equivalent 'user
> scripts' for important competitors (hg, git, etc)?
> /john

I don't think its all that useful beyond ballpark comparisons. (E.g.
'bzr is way to slow on commit') - And just having a performance metric
for our own commit is enough to tell us that :). Folk have in the past
ruled bzr out because bzr was *too slow*. So we *have* to fix that and
get good performance into our core set of design principles... which we
are doing!

That said, I dont think being the *fastest* is the key to having folk
adopt bzr: I think being the most lovable tool is the key, and we should
be careful not to obsess on performance beyond the point where it starts
to harm our lovability. Comparing bzr to other systems purely on
performance would make it harder for *other people* to remember that
performance is just one aspect of the system, and given that we have
(IMO) the best set of 'correctness' features and cross platform
portability and interoperability of the current distributed VCS systems
we should really emphasis that.

In a related way, it would be a mistake to set our performance goals on
what other tools achieve. I say this because of two key reasons:
Firstly, other existing, fast tools may not be the fastest! Theres no
reason to support that we are any less capable of creating a very fast
system. Secondly, we need to remember that our feature set and
portability constraints may well impose a performance penalty in that we
may have to do more work than a different system, and as such any
performance comparisons are *not* a comparison of the same amount of
work : we'd want comparisons which do test equivalent work if we want to
be able to compare them.

I think a much more useful thing is to be able to say 'bzr should be
able to commit a 50000 file tree, with 10 files changed, in 2 seconds on
a core duo with 512MB of ram.' or some similar goal, and then be able to
assess, repeatedly, whether bzr meets that metric, and do so with fine
control - e.g. with cold cache and hot cache, with different versions of
bzr.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070530/748c78b5/attachment-0001.pgp