RE: git performance

[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", 
which it would use for files that aren't "open"; for files with this flag, 
the check for index freshness would always say it's fresh without looking 
at the filesystem. Then you'd just have a config option to check out files 
as "not open" (and not writeable), and have a "git open" program that 
would chmod files and get their real stat info.

Of course, git is tuned for cases where the modify/build/test cycle 
requires stat() (or worse) on every file.

	-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