Re: git performance

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Oct 24, 2008, 03:56 UTC
Message-ID: <alpine.LNX.1.00.0810232237060.19665@iabervon.org>
In-Reply-To: <20081024072412.6117@nanako3.lavabit.com>

On Fri, 24 Oct 2008, Nanako Shiraishi wrote:

Show 19 quoted lines

> Quoting Daniel Barkalow <barkalow@iabervon.org>:
> 
> > On Wed, 22 Oct 2008, Edward Ned Harvey wrote:
> >
> >> Out of curiosity, what are they talking about, when they say "git is 
> >> fast?"  Just the fact that it's all local disk, or is there more to it 
> >> than that?  I could see - git would probably outperform perforce for 
> >> versioning of large files (let's say iso files) to benefit from 
> >> sustained local disk IO, while perforce would probably outperform 
> >> anything I can think of, operating on thousands of tiny files, because 
> >> it will never walk the tree. 
> >
> > It shouldn't be too hard to make git work like perforce with respect to 
> > walking the tree. git keeps an index of the stat() info it saw when it 
> > last looked at files, and only looks at the contents of files whose stat() 
> > info has changed. In order to have it work like perforce, it would just 
> > need to have a flag in the stat() info index for "don't even bother", 
> 
> Are you describing the "assume unchanged bit"?

Yes, but with the user write mode bit in the filesystem set to no-assume-unchanged, which is how Perforce users cope with it. I hadn't realized it had been implemented to get set on a per-file basis, rather than just as a global setting that caused it to not stat() anything except right when it was told to update.

	-Daniel
*This .sig left intentionally blank*