Subject: Re: [PATCH] Add the --submodule-summary option to the diff option family

From: Jens Lehmann <[email-masked]>
Date: Wed, 07 Oct 2009 21:32:54 +0200

Junio C Hamano schrieb:
> Jens Lehmann <[email-masked]> 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