Bazaar-NG vs. Mercurial -- speed comparison

[John Arbash Meinel]

Bryan O'Sullivan wrote:
> John A Meinel <john <at> arbash-meinel.com> writes:
> 
>> First, mercurial use a custom server rather than working off of 'plain'
>> http/sftp.
> 
> It actually works over plain http, though you can't push over HTTP yet.

I'm guessing that it would be slower over plain HTTP, though I obviously
don't have any actual tests to prove that.

> 
>> This does give it a huge latency advantage. It has some
>> drawbacks, as in it is another thing that needs to be setup, holes
>> opened in firewalls, etc.
> 
> We tunnel over regular ssh, or you can install a CGI script to serve
> over an existing http server on port 80.  Either mechanism takes about
> two minutes to set up and debug.
> 
>> I should revisit my
>> performance testing with knits.
> 
> My performance tests were run using knits.

(I was saying I need to perf test bzr again now that we have knits. I
was guessing your tests were knits as well)

> 
>> Mercurial has used 'revfiles' for a long
>> time, which are very similar to knits.
> 
> The only similarity is that both are append-only.  Revlog files do not
> represent a weave, while knits do.  I suspect that you have to read an entire
> knit file to reconstruct the most recent revision, while a revlog file has
> a small upper bound on the amount of data you have to read to reconstruct
> any revision.

Well, knits actually keep an annotated full-copy. (Like revlog contain a
full-text). So to build a weave you only need to read back to the latest
full annotation.
That said, representing things in memory as weaves does impose some
overhead. But knits do provide support for only reading a little bit,
rather than having to read the whole thing.

> 
>> (Also, on one of my
>> production servers, I don't install gcc, which makes mercurial difficult
>> to install, and it is where I host some repositories)
> 
> Most people install Mercurial and Bazaar-NG from binary packages, though,
> so this is not an issue for either in practice.

Except for all of us developers. :) And a lot of the time the software
is beta. And anyone using Redhat servers, etc. mercurial-0.8-1 is in
FC4, but I didn't find anything in RHEL up2date.

No, this isn't a show-stopper. But it is a little bit of something.

> 
>> Bzr could be better about not having to load support for all of its
>> features until they are actually needed. 'hg' actually uses a solution
>> called 'demandload', which we probably could just move directly into the
>> bzr code.
> 
> You should grab it and use it.  It's very nice.  It imposes a one-time cost
> when an attribute of a demand-loaded symbol is looked up; after that, the
> importing namespace is patched with the real module, so there's no
> subsequent cost.

I agree. I put it on my todo list.

> 
>> Timing hg clone of hg code isn't quite the same as timing bzr.dev code.
> 
> Right.  That's why I used a Linux kernel tree for my benchmarks.
> 

Well, your clone benchmarks are all for hg using hg, and bzr using bzr.
And the bzr source tree is 4x as large.

>> Notice that this time, we actually create a new branch faster than hg
>> without using hardlinks, and in a system which has approximately a 1.1s
>> startup overhead.
> 
> Actually, this is not the case.  See below:
> 
>> Now, I admit to a little bit of cheating, in that I didn't create
>> working trees here.
> 
> You did, in the Mercurial case.  You need to use "clone -U" to avoid
> populating the working directory.
> 
>> But I did want to make people aware that hg isn't 30x faster
>> than bzr. In many cases it is more in the 4-7x range.
> 
> I only found one case where hg was 33x faster, and that was cloning over
> a WAN, where bzr seems to be doing something very inefficient.
> 
> But in most other cases, it was more like 8x to 12x faster in
> my tests.
> 

Well, your 33x faster was also dealing with copying 4x the data. So it
is possible that if you take 33x / 4x you get ~8x again. (And your local
clone is 13.8 vs 0.68 which is 20x/4 = 5).

But I will also say bzr is slow to create working trees. For mercurial
are you actually extracting the text from the repository, or are you
just copying the files on disk?

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060518/e2483bf3/attachment.pgp