Re: git performance

[Daniel Barkalow <barkalow@xxxxxxxxxxxx>]

On Fri, 24 Oct 2008, Nanako Shiraishi wrote:

> Quoting Daniel Barkalow <barkalow@xxxxxxxxxxxx>:
> 
> > 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*
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html