Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > But that's not what I'm talking about here, I'm just saying that we'd do > a normal "make test" where we write the gcov tests per-test into > t/test-results/t0001 and join them at the end of the run. OK, instead of per directory .gcov, we allow separate recording area per test, ... > No, on a multi-core machine the inability to run with -jN is the main > factor in making this run slow. E.g. on my 8 core box the tests run in > 2-3 minutes with -j8, with -j1 it's 20-25 minutes. ... and that would make it easier to run the same binary from different tests in parallel, which makes sense. I missed that you were talking about running tests in parallel when you brought up the "running tests can be made cheaper". > So I'm wondering if the desire to keep the old coverage report around is > synonymous with the current implementation running so slowly. Possibly.
