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

Jens Lehmann [off-list ref] writes:

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.

It appears that your "simulation" is to have changes in all submodules and
nowhere else in the tree.  I have to wonder how common would that be.  If
I have been working in the subprojects without changing the superproject
at all, I would likely to be in one of the subproject directories and my
"git diff" would not even have to trigger this codepath.  If we have on
the other hand changes in the superproject, showing them would cost us
equally in both approaches.

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.

Thanks.  I was worried if the forking to ensure correctness may sactifice
performance so much to be unusable, but it does not seem to be the case,
given the above comparision.

I didn't look at the code but presumably it uses the run_command()
interface and cleanly written?

Hi,

On Wed, 7 Oct 2009, Junio C Hamano wrote:

Jens Lehmann [off-list ref] writes:

quoted

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.

It appears that your "simulation" is to have changes in all submodules 
and nowhere else in the tree.  I have to wonder how common would that 
be.  If I have been working in the subprojects without changing the 
superproject at all, I would likely to be in one of the subproject 
directories and my "git diff" would not even have to trigger this 
codepath.  If we have on the other hand changes in the superproject, 
showing them would cost us equally in both approaches.

quoted

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.

Thanks.  I was worried if the forking to ensure correctness may sactifice
performance so much to be unusable, but it does not seem to be the case,
given the above comparision.

I didn't look at the code but presumably it uses the run_command()
interface and cleanly written?

You seem to be rather unconvinced by rather convincing numbers.

Therefore, I will continue working on the --submodule-summary stuff in 
4msysgit.git.

Ciao,
Dscho