bzr vs. git repository

bzr vs. git repository

[Werner LEMBERG]

I've now done a comparison between the network traffic of git and bzr,
using nethogs.

git pull (git://repo.or.cz/emacs.git, git version 1.7.1.78) :

  Update from

      commit 6be816dee8c9720dc39ff235b7b31d4190e06d57
      Author: Stefan Monnier <monnier@iro.umontreal.ca>
      Date:   Fri Dec 10 15:00:25 2010 -0500

  to

      commit 2d33d18337320f5c0cd1c0627caa6528f7050b29
      Author: Michael Albinus <michael.albinus@gmx.de>
      Date:   Fri Dec 31 20:57:05 2010 +0100

  sent:      194k
  received: 6400k


bzr pull (bzr+ssh, bzr version 2.0.5):

  Update from

      revno: 102636
      committer: Glenn Morris <rgm@gnu.org>
      branch nick: trunk
      timestamp: Fri 2010-12-10 18:54:07 -0800

  to

      revno: 102734
      committer: Chong Yidong <cyd@stupidchicken.com>
      branch nick: trunk
      timestamp: Sat 2011-01-01 01:02:36 -0500

  sent:       512k
  received: 19357k

As you can see, bzr still needs about three times more bandwidth in
both receiving and sending...


     Werner

Re: bzr vs. git repository

[Eli Zaretskii]

> Date: Sat, 01 Jan 2011 09:28:38 +0100 (CET)
> From: Werner LEMBERG <wl@gnu.org>
> 
> As you can see, bzr still needs about three times more bandwidth in
> both receiving and sending...

So what?  In my testing, both on GNU/Linux and on MS-Windows,
update/pull times are very similar (with bzr slightly _faster_ on
GNU/Linux).  That includes the initial "bzr branch" vs "git clone" (10
min for bzr vs 15 for git).  Other common operations are mostly
comparable as well.  (A great surprise was "annotate", which, for
xdisp.c, took 1 minute with bzr, but a whopping 4.5 minutes with git.
But I see that as a curiosity.)

I don't think this will convince anyone to switch, but frankly, I no
longer understand what is all that fuss with git's speed.  Coupled
with the fact that the git repository seems to be updated only once in
a while, I see no good reasons to use git at all, at least not for
reasons of speed.

Re: bzr vs. git repository

[Werner LEMBERG]

>> As you can see, bzr still needs about three times more bandwidth in
>> both receiving and sending...
> 
> I don't think this will convince anyone to switch, but frankly, I no
> longer understand what is all that fuss with git's speed.

I don't want to convince anyone, I just report the issue.  You are
overreacting.


    Werner

Re: bzr vs. git repository

[Eli Zaretskii]

> Date: Sat, 01 Jan 2011 10:54:45 +0100 (CET)
> Cc: emacs-devel@gnu.org
> From: Werner LEMBERG <wl@gnu.org>
> 
> 
> >> As you can see, bzr still needs about three times more bandwidth in
> >> both receiving and sending...
> > 
> > I don't think this will convince anyone to switch, but frankly, I no
> > longer understand what is all that fuss with git's speed.
> 
> I don't want to convince anyone, I just report the issue.  You are
> overreacting.

It's hard to overreact, with all the git propaganda that goes on
here.  For a project that decided long ago to use bzr, this borders on
being inappropriate.  Posting this on the Bazaar mailing list would be
TRT, IMO.  It's always a Good Thing to get the developers think about
getting their software more efficient.  But posting this here can
never make bzr hog less of the bandwidth, so I don't see why would you
do this except to tease.

More to the point: You've analyzed the net traffic, but not the other
aspects of performance, like file I/O, CPU load, memory consumption,
etc.  At least in principle, there are trade-offs between all of
these.  And depending on the particular system configuration of the
end users, the ones that matter could be other than the net traffic.

In my testing, the differences in the net traffic are not noticeable
in the end result.  And the end result is what really matters for
users (as long as speed and efficiency in general is what we are
talking about).

Re: bzr vs. git repository

[Werner LEMBERG]

> Posting this on the Bazaar mailing list would be TRT, IMO.  It's
> always a Good Thing to get the developers think about getting their
> software more efficient.  But posting this here can never make bzr
> hog less of the bandwidth, so I don't see why would you do this
> except to tease.

RMS explicitly has asked for that info a few months ago, and only now
I was able to provide it for various reasons.  Since the discussion
then happened on this very list, I found it appropriate to post it
here too.

I suggest to forget the whole issue.


    Werner

Re: bzr vs. git repository

[Óscar Fuentes]

Werner LEMBERG <wl@gnu.org> writes:

>> Posting this on the Bazaar mailing list would be TRT, IMO.  It's
>> always a Good Thing to get the developers think about getting their
>> software more efficient.  But posting this here can never make bzr
>> hog less of the bandwidth, so I don't see why would you do this
>> except to tease.
>
> RMS explicitly has asked for that info a few months ago, and only now
> I was able to provide it for various reasons.  Since the discussion
> then happened on this very list, I found it appropriate to post it
> here too.

I did quite a few resource usage comparisions back on the days before
the transition to bzr. They were posted on the bzr ml. The response from
the developers was "bzr is fast enough and we wont devote more time to
performance enhancements." However, the data was enough motivation for
one or two developers to tweak some parts of bzr, with visible
results. The impression I got is that further improvements would be very
hard to achieve.

> I suggest to forget the whole issue.

Yes, please.

Re: bzr vs. git repository

[Frank Schmitt]

Werner LEMBERG <wl@gnu.org> writes:

>>> As you can see, bzr still needs about three times more bandwidth in
>>> both receiving and sending...
>> 
>> I don't think this will convince anyone to switch, but frankly, I no
>> longer understand what is all that fuss with git's speed.
>
> I don't want to convince anyone, I just report the issue.  You are
> overreacting.

Honestly, as a lurker on this list, I really wonder how many hours of
developer time was spend in the last few years on discussions about
various aspects of version control systems. I don't dare to imagine all
the cool stuff which could have been created if this time has been spend
on software development instead.

-- 
Have you ever considered how much text can fit in eighty columns?  Given that a
signature typically contains up to four lines of text, this space allows you to
attach a tremendous amount of valuable information to your messages.  Seize the
opportunity and don't waste your signature on bullshit that nobody cares about.

Re: bzr vs. git repository

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 01 Jan 2011 09:28:38 +0100 (CET)
>> From: Werner LEMBERG <wl@gnu.org>
>> 
>> As you can see, bzr still needs about three times more bandwidth in
>> both receiving and sending...
>
> So what?  In my testing, both on GNU/Linux and on MS-Windows,
> update/pull times are very similar (with bzr slightly _faster_ on
> GNU/Linux).  That includes the initial "bzr branch" vs "git clone" (10
> min for bzr vs 15 for git).  Other common operations are mostly
> comparable as well.  (A great surprise was "annotate", which, for
> xdisp.c, took 1 minute with bzr, but a whopping 4.5 minutes with git.
> But I see that as a curiosity.)

That is not a curiosity but a consequence of git's design choices.  git
stores file system snapshots and a DAG of commits.  Everything else is
reconstructed on-the-fly when you ask for it.  As a result, renaming
files in git is indistinguishable from deleting the old file and
creating a new file with the old content.

That makes git a handy tool for analyzing, say, a progression of
distribution tarballs.  You just check in all the tarballs into a git
repository, and you get renames, moves, copied content, tracking of
material and so on out _gratis_ because git never stores those kind of
things but instead knows how to make them up.

Now "git annotate" is an example where git constructs a history of
content through file renaming and subfile copying, and does it at the
time of "git annotate".  That's the reason git annotate is _expected_ to
be an expensive operation, and you have various options to tell it just
how expensive it may do its work, depending on the amount of
reconstructed information you'd like to see.

Bazaar does not do this.  It just reproduces the history according to
the file operation history that has been explicitly stored into Bazaar
by the user.

If you store a sequence of unpacked tarballs into Bazaar and ask for the
history of some content, Bazaar will not track the content across
subfile copying and file renames because it has not been _told_ about
them explicitly.

-- 
David Kastrup

Re: bzr vs. git repository

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Sat, 01 Jan 2011 11:14:42 +0100
> 
> > (A great surprise was "annotate", which, for xdisp.c, took 1
> > minute with bzr, but a whopping 4.5 minutes with git.  But I see
> > that as a curiosity.)
> 
> That is not a curiosity but a consequence of git's design choices.

Yes, I understand that (and thanks for the details).  I meant
"curiosity" as in "not really representative for comparison purposes".
Sorry for unfortunate choice of words.

Re: bzr vs. git repository

[Eli Zaretskii]

> Date: Sat, 01 Jan 2011 09:28:38 +0100 (CET)
> From: Werner LEMBERG <wl@gnu.org>
> 
> bzr pull (bzr+ssh, bzr version 2.0.5):
> 
>   Update from
> 
>       revno: 102636
>       committer: Glenn Morris <rgm@gnu.org>
>       branch nick: trunk
>       timestamp: Fri 2010-12-10 18:54:07 -0800
> 
>   to
> 
>       revno: 102734
>       committer: Chong Yidong <cyd@stupidchicken.com>
>       branch nick: trunk
>       timestamp: Sat 2011-01-01 01:02:36 -0500
> 
>   sent:       512k
>   received: 19357k

FWIW, "bzr up" which brings only 26 of these 98 revisions on the trunk
shows this network information in my .bzr.log file:

  Transferred: 5238kB (99.0kB/s r:5234kB w:3kB)

and I never see the amount of bytes being sent by bzr anywhere close
to 512kB, since we switched to bzr+ssh.  It's always 3k to 4k, even
though I generally update once a week.  But perhaps that's due to the
fact that bzr doesn't count the traffic accurately.

Re: bzr vs. git repository

[Stefan Monnier]

> As you can see, bzr still needs about three times more bandwidth in
> both receiving and sending...

I'm glad to see that Bzr is now within an acceptable factor of Git in
this respect.


        Stefan

Re: bzr vs. git repository

[Richard Stallman]

I fowarded this to the Bzr maintainers in case they can do something
to improve it.

-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org