On Fri, Oct 22, 2021 at 12:51:11PM +0200, Ævar Arnfjörð Bjarmason wrote: > Yes, the same numbers are noted in the 7/8 commit message. I.e. it's > slower on -j1, but faster with higher -j<n> numbers. > > Aside from any changes I'm proposing here it seems rather pointless to > me to optimize the runtime of -j1 runs. > > I think we use those in e.g. CI, so of course if they become *really* > slow it will matter, but the purpose of this change is to make hacking > on git easier, both in terms of runtime and discovering what the > Makefile is doing wih V=1. > > I think anyone hacking on git is going to be on a system with -j2 at > least. So again, separate from these specific changes, if we've got a > change that speeds up -jN runs at the cost of a -j1 run that seems like > good thing. It seems weird to me to assume that all of our processors are available to build command-list.h. In most cases you are not running "make -j16 command-list.h", but rather "make -j16", and those other processors are doing useful things, like say, building actual C code. So counting CPU time is the interesting thing, because every cycle you save there gets used for other work. And "make -j1" just brings wall-clock and CPU time together. -Peff
