Rather than assume such coarse delays, re-use existing logic for probing the current filesystem resolution. This speeds up the testsuite significantly. On my system, it speeds -j1 up quite a lot -- by ~30%. While I didn't gather many samples to produce a statistically significant distribution, my runs seem to be fairly consistent with the values below with deviations of <1 minute.
$ time make -j1 Before After real 33m17.182s real 23m33.557s user 12m12.145s user 12m12.763s sys 1m52.308s sys 1m52.853s $ time make -j32 Before After real 1m35.874s real 1m4.908s user 14m24.664s user 15m58.663s sys 2m9.297s sys 2m27.393s * configure.ac: Set test delays to am_cv_filesystem_timestamp_resolution. --- configure.ac | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/configure.ac b/configure.ac index dcf2d95566a0..d3a67d5ffec9 100644 --- a/configure.ac +++ b/configure.ac @@ -172,15 +172,7 @@ result=no test "x$am_cv_prog_ln" = xln && result=yes AC_MSG_RESULT([$result]) -# The amount we should wait after modifying files depends on the platform. -# On Windows '95, '98 and ME, files modifications have 2-seconds -# granularity and can be up to 3 seconds in the future w.r.t. the -# system clock. When it is important to ensure one file is older -# than another we wait at least 5 seconds between creations. -case $build in - *-pc-msdosdjgpp) MODIFICATION_DELAY=5;; - *) MODIFICATION_DELAY=2;; -esac +MODIFICATION_DELAY=$am_cv_filesystem_timestamp_resolution AC_SUBST([MODIFICATION_DELAY]) ## ------------------------------------------- ## -- 2.39.0