RE: git performance

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Oct 23, 2008, 18:31 UTC
Message-ID: <alpine.LNX.1.00.0810231346520.19665@iabervon.org>
In-Reply-To: <000901c93490$e0c40ed0$a24c2c70$@com>

On Wed, 22 Oct 2008, Edward Ned Harvey wrote:

Show 7 quoted lines

> 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*