--- Begin Message ---
|
Subject: |
[PATCH 2/2] tests: reuse am_cv_filesystem_timestamp_resolution |
|
Date: |
Sat, 14 Jan 2023 03:02:15 -0500 |
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
--- End Message ---