Re: Why Git is so fast (was: Re: Eric Sink's blog - notes on git, dscms and a "whole product" approach)
- From
- david@lang.hm <david@lang.hm>
- Date
- May 1, 2009, 19:13 UTC
- Message-ID
- <alpine.DEB.1.10.0905011211080.15782@asgard>
- In-Reply-To
- <20090501190854.GA13770@coredump.intra.peff.net>
On Fri, 1 May 2009, Jeff King wrote:
Show 31 quoted lines
> On Fri, May 01, 2009 at 02:43:49PM -0400, Linus Torvalds wrote: > >>> Like all generalizations, this is only mostly true. Fast network servers >>> with big caches can outperform disks for some loads. >> [...] >> In contrast, a workstation with local filesystems and enough memory to >> cache it well will just be a lot nicer. >> [...] >>> I have never used perforce, but I get the impression that it is more >>> optimized for such a situation. >> >> I doubt it. I suspect git will outperform pretty much anything else in >> that kind of situation too. > > Thanks for the analysis; what you said makes sense to me. However, there > is at least one case of somebody complaining that git doesn't scale as > well as perforce for their load: > > http://gandolf.homelinux.org/blog/index.php?id=50 > > Part of his issue is with git-p4 sucking, which it probably does. But > part of it sounds like he has a gigantic workload (the description of > which sounds silly to me, but I respect the fact that he is probably > describing standard practice among some companies), and that workload is > just a little too gigantic for the workstations to handle. I.e., by > throwing resources at the central server they can avoid throwing as many > at each workstation. > > But there are so few details it's hard to say whether he's doing > something else wrong or suboptimally. He does mention Windows, which > IIRC has horrific stat performance.
the key thing for his problem is the support for large binary objects. there was discussion here a few weeks ago about ways to handle such things without trying to pull them into packs. I suspect that solving those sorts of issues would go a long way towards closing the gap on this workload.
there may be issues in doing a clone for repositories that large, I don't remember exactly what happens when you have something larger than 4G to send in a clone.
David Lang