Jens Lehmann <Jens.Lehmann@xxxxxx> 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? -- 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