Performance requirements for bzr checkout --lightweight

[David Cournapeau]

John Arbash Meinel wrote:
> James Westby wrote:
> > Hi,
>
> > I wasn't sure what the best way to raise this issue was, so I thought
> > I would at least start with a mail to the list.
>
> > First of all, let me say that I realise that performance has been
> > a major focus for a long while now, and things have improved
> > a lot. I do not wish this email to insult anybody's work.
>
> While that is true 'checkout --lightweight' has *never* been a primary
> focus.
> It won't really scale, it doesn't let you do a local commit, etc. Shallow
> branches are really the better solution for this, we just haven't
> gotten there
> yet.
>
> I'm not saying we can't spend some time to make it reasonably faster, I'm
> mostly just pointing out that it is somewhat slow because it isn't
> something
> we've ever optimized for.
>
> > There has been a discussion on ubuntu-devel recently about
> > DistributedDevelopment, the plan to make all of Ubuntu available
> > in bzr. One of the use cases that people are concerned about
> > is sponsorhip of a package that they have not touched before,
> > which is a fairly common occurrence. This currently involves
> > getting the latest version of the code, applying a diff, building
> > an testing, and them uploading.
>
> > In this discussion it was noted that the first time looking at
> > a package is one area where bzr is going to be slower than
> > current tools, as there is more to do than a simple "apt-get
> > source". Some timings were done, and people had widely
> > varying results, but testing with the latest and greatest
> > showed that the times for "checkout --lightweight" were
> > heading towards those of "apt-get source", but still
> > too far away for comfort.
>
> I'm glad you're having the discussion. I would be more curious to know
> what
> the real numbers are. It is going to be very hard to beat "wget
> foo.tar.bz2"
> because that is rather focused on just snapshotting the tip.
> We can do a lot better once you already *have* a snapshot, as we can do
> incremental updates (which .tar.bz2 doesn't do well).
>
>
> > I realise that emphasising one operation doesn't necessarily
> > help with performance optimisation, but I would like to
> > ask for some attention to be paid to this operation. Ideally
> > a lightweight checkout of a packaging branch would take less
> > than 150% or 200% of the time for an "apt-get source" of the
> > same package.
>
> So does this mean we are at 100x, 10x, 3x? There is a lot of variance
> here. If
> we were at 210%, *I* probably wouldn't focus on it (whether other
> people feel
> it is critical). If we are at 100x then something needs to be done.

I think a better comparison would be the time to get a svn checkout.
Currently, many projects use svn, and if they think about going to bzr,
that's what they will be comparing. The ability to get access to the
code to look at it, or only installing from sources is important.

Currently, for the projects I am the most involved with, bzr branch is
one order of magnitude slower than svn co, for small/mid-size projects
(several thousand of files max). I suspect this has a lot to do with
latency as usual, since checkout vs checkout --lightweight does not make
much different on the timings here. Another thing which strikes me is
the huge variance in the numbers with bzr, depending on the different
operations and my internet connection; of course, network issues vary a
lot depending on the connection, but this never bothered me with hg, git
or svn, and bothers me quite a bit with bzr (this happens at any
version, and the order of magnitude can still be seen with bzr 1.6.1rc1).

There is a huge variance when using bzr with network that I just don't
see with other tools. I don't know what I can do to help debugging those
problems, but I would be happy to help.

cheers,

David