User: Password:
|
|
Subscribe / Log in / New account

Bazaar on the slow track

Bazaar on the slow track

Posted Sep 11, 2012 22:55 UTC (Tue) by amk (subscriber, #19)
Parent article: Bazaar on the slow track

I think bzr lost mindshare early on due to unfortunate performance problems. The number of network operations wasn't optimized very carefully, so checking out and pushing took a long time on large repositories. Emacs wrestled with this a lot in converting from CVS to bzr; see http://osdir.com/ml/bazaar/2009-11/msg00912.html for an example. Later releases reduced the amount of network traffic, but I think bzr had already acquired a reputation as 'the DVCS that isn't fast', and so users are instead drawn to git or Mercurial.


(Log in to post comments)

Bazaar on the slow track

Posted Sep 12, 2012 2:08 UTC (Wed) by SEJeff (subscriber, #51588) [Link]

I'd argue that the problem wasn't speed (although that was important), but repository format. bzr changed on-disk format in non-compatible ways what, 3 times? I seriously forget. Sure git has added features in forwards compatible ways, but you won't see any issues with pushing to different versioned remote repos using git. You can with bzr.

That made it an absolute nonstarter for some things I was working on several years ago

Bazaar on the slow track

Posted Sep 12, 2012 8:12 UTC (Wed) by hrw (guest, #44826) [Link]

Speed was issue. At Linaro we imported gcc into bzr and then pointed Bazaar developers to it to show how slow it is. Lot of things got improved in last 2 years.

But personally I prefer git.

Bazaar on the slow track

Posted Sep 18, 2012 20:36 UTC (Tue) by fw (subscriber, #26023) [Link]

Just for testing, I pulled about 9.5 months of Emacs development using bzr 2.6.0dev2. It took 5.5 minutes and roughly 170 MB of network traffic. Cloning the entire Git mirror took 14 minutes and 690 MB. Now cloning from scratch is always more efficient, but these numbers still don't look very good for bzr.

Bazaar on the slow track

Posted Sep 19, 2012 11:03 UTC (Wed) by hummassa (subscriber, #307) [Link]

> I pulled about 9.5 months of Emacs development using bzr 2.6.0dev2. It took 5.5 minutes and roughly 170 MB of network traffic. Cloning the entire Git mirror took 14 minutes and 690 MB

Care to elaborate that? You just stated that git was 3x slower than bzr, so I'm confused.

Bazaar on the slow track

Posted Sep 19, 2012 11:17 UTC (Wed) by hummassa (subscriber, #307) [Link]

After re-reading, I *think* the "9.5 months" mean that the "entire git mirror" refers to more development time... (maybe twenty or so years?) can you clarify this? And as you stated, full mirroring is really fast...

Bazaar on the slow track

Posted Sep 21, 2012 19:37 UTC (Fri) by fw (subscriber, #26023) [Link]

Git had much more history to pull. I tried again with the last few days (both incremental this time), and the speed is comparable (15 seconds each). Git still transfers slightly less data (3.8 MB vs 4.3 MB). I should probably do this comparison again after two weeks.

Bazaar on the slow track

Posted Oct 3, 2012 10:07 UTC (Wed) by fw (subscriber, #26023) [Link]

I did another test, and the numbers are now:

bzr: 41s, 27.7 MiB
git: 35s, 24.9 MiB

So bzr and git are roughly in the same ballpark, at least for this test (pulling changes into a local repository which hasn't seen any local changes).

Bazaar on the slow track

Posted Sep 19, 2012 21:52 UTC (Wed) by nix (subscriber, #2304) [Link]

Quite. I just pulled the last five days of Emacs development with bzr 2.5. It pulled down 16905Kb at wildly varying rates all well below line speed, and re-evaluated its infuriating 'estimate' of amount to be transferred five times. Does anyone believe that Emacs actually had 17Mb of changes in the last week? You'd be right.

Getting a diff of the changes on trunk -- entirely in core -- took four seconds (not too shabby but still terribly slow compared to git, where in-core diffs often run at rates in excess of 30,000 lines per second), and revealed

311 files changed, 3025 insertions(+), 2658 deletions(-)

A wc of the output says

12952 55987 447812

so "bzr pull" had to receive roughly thirty times as much data as was actually changed, and that's despite the fact that patches contain lots of redundant context info that hasn't actually changed in any way at all.

I'm sorry, but no matter which way you slice it, bzr is still hilariously inefficient. It may not be *unusably* inefficient anymore, but that's damning with very faint praise.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds