From: david@lang.hm
Date: Fri, 01 May 2009 19:13:50 GMT
Subject: Re: Why Git is so fast (was: Re: Eric Sink's blog - notes on git, dscms and a "whole product" approach)
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:

> 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