Junio C Hamano schrieb: > Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > >>> But I really, really, really want to avoid a fork() in the common case. I >>> do have some users on Windows, and I do have a few submodules in that >>> project. Having too many fork() calls there would just give Git a bad >>> reputation. And it has enough of that, it does not need more. >> Me too thinks performance matters here. We do have a repo at my dayjob >> with more than a handful of submodules and its main target platform is >> windows ... so having that perform nicely is a win for us. > > Numbers? Here they are: First i did them with the repo at hand, current msysgit master with Dscho's git-repo checked out: without fork : real 0m0.672s with fork : real 0m0.781s So here it's a about 16% slower when using fork() (and both are generating about 7270 shortlog entries). But i thought this to be a rather unusual situation, having only one submodule being changed by 7270 commits ... So i took a live repo from my dayjob containing 8 submodules. In each submodule i did a "git checkout HEAD^" to simulate one change. And then i got: without fork : real 0m0.203s with fork : real 0m0.453s This is a degradation of more than 120% because of the fork()s. And just for fun i ran the scripted submodule summary too: scripted : real 0m3.437s So the forked version outperforms the scripted version by a factor of 7, while the speedup from Dscho's original proposal is almost 17fold. (If i did my computations right, the extra costs for each changed submodule are a bit more than 30ms when fork()ing. Dscho's version doesn't seem to suffer from changed submodules at all, i measured 0.203s for both versions before i did the submodule init and update). (Best of three, "time git diff --submodule-summary". My system is an Athlon64x2 4600+ with WindowsXP) Jens -- 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