Am 10.03.2014 12:42, schrieb Dennis Luehring:
> Am 10.03.2014 12:28, schrieb demerphq:
>> I had the impression, and I would not be surprised if they had the
>> impression that the git development community is relatively
>> unconcerned about performance issues on larger repositories.
>
> so the question is if the git community is interested in beeing competive in
> such
> large scale scenarios - something what mercurial seems to be now out of the
> box
>

Advertising

The hgwatchman site claims (https://bitbucket.org/facebook/hgwatchman)
"On a real-world repository with over 200,000 files, hg status normally takes
over 3 seconds. With hgwatchman it takes under 0.6 seconds."
There have been a few performance improvements in git status to support such
large repositories. I just re-checked git status performance with the WebKit
repo (~200k files):
Linux (with core.preloadIndex)
git status -uall: 0.620s
git status -uno : 0.255s
Windows (with core.preloadIndex and core.fscache)
git status -uall: 1.006s
git status -uno : 0.695s
Of course, for more reliable benchmark data, you'd have to compare the same
repo on the same platform. But on first glance, it seems that mercurial with
hgwatchman extension may be as fast as git is out of the box, not the other way
around.
This comes at the cost of running a background daemon, which may slow down the
entire system. E.g. if the daemon activates whenever the compiler creates a .o
file, it will probably slow down build performance.
Note that hgwatchman doesn't support Windows, so git is probably much faster
there.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html