On Tue, Jun 10, 2014 at 3:58 PM, hasufell <[email protected]> wrote: > > interesting read: > http://thread.gmane.org/gmane.comp.version-control.git/189776 > > Does any1 know what fb currently uses or if any of these issues have > been resolved? >
Not sure, but I did a git status on the actual gentoo-x86 converted repository (all commits) and it took about 30s. It has about 130k files in it, and I suspect that the number of files matters a good deal. Git status should need to compare the working tree (a directory tree) against the index (which is a flat file I think) against the head (which is a tree full of tree files). The index should perform very well as the number of files grow, but the tree and head should become much harder to traverse as the number of subdirectories grow (assuming the filesystem design requires seeks to navigate to subdirectories but not to read the contents of a directory). Our tree isn't all that deep. I'd think the pathological case for git would be a repository in which there is a single file 1.5M subdirs deep. That would require 1.5M trees in the repository to store for a single file, or 1.5M filesystem readdirs to traverse the working tree. If your repository were flat I'd think that git would perform reasonably well, though it would still have to compare all those hashes to find out what changed (but how long can it take a CPU to compare 1.5M pre-computed hashes?). Rich
