Re: 1.16.90 regression: configure now takes 7 seconds to start

Bruno Haible wrote:
> [I'm writing to [email protected] because [email protected]
> appears to be equivalent to /dev/null: no echo in
> https://lists.gnu.org/archive/html/bug-automake/2024-06/threads.html
> nor in https://debbugs.gnu.org/cgi/pkgreport.cgi?package=automake,
> even after several hours.]
>
> In configure scripts generated by Autoconf 2.72 and Automake 1.16.90,
> one of the early tests
>   checking filesystem timestamp resolution...
> takes 7 seconds! Seen e.g. on NetBSD 10.0.
>
> Logging the execution time, via
>   sh -x ./configure 2>&1 | gawk '{ print strftime("%H:%M:%S"), $0; fflush(); }' > log1
> I get the attached output. There are
>   6x sleep 1
>   4x sleep 0.1
> That is, 6.4 seconds are wasted in sleeps. IBM software may do this;
> but GNU software shouldn't.
>
> AFAIU, the 4x sleep 0.1 are to determine whether
> am_cv_filesystem_timestamp_resolution should be set to 0.1 or to 1.
> OK, so be it.
>
> But the 6x sleep 1 are to determine whether
> am_cv_filesystem_timestamp_resolution should be set to 1 or 2.
> 2 is known to be the case only for FAT/VFAT file systems. Therefore
> here is a proposed patch to speed this up. On NetBSD, it reduces
> the execution time of the test from ca. 7 seconds to ca. 0.5 seconds.

The problem with the proposed patch is that it tries to read a 
filesystem name instead of testing for the feature.  This would not be 
portable to new systems that use a different name for their FAT 
filesystem driver.

I think the test can be better optimized for the common case by first 
checking if stat(1) from GNU coreutils is available ([[case `stat 
--version` in *coreutils*) YES;; *) NO;; esac]]) and, if it is (common 
case and definitely so on the GNU system), checking [[case `stat 
--format=%y .` in *:??.000000000) SUBSEC_RESOLUTION=no;; *) 
SUBSEC_RESOLUTION=yes;; esac]] to determine if sub-second timestamps are 
likely to be available; this has a 1-in-actual-ticks-per-second of 
giving a false negative.  These checks would be very fast, so could also 
be repeated with the access and inode change timestamps and/or extended 
to other files (`stat *`) for better certainty.  The basic concept 
should be sound, although the pattern matching used in the examples is a 
first cut.

The essential idea is that the fractional part beyond what the 
filesystem actually records will always read as zero, and unpacking an 
archive is not instant, so we should see every implemented fractional 
bit set at least once across files in the tree containing configure.

To handle filesystems with 2-second timestamp resolution, check the 
timestamp on configure, and arrange for autoconf to ensure that the 
timestamp of a generated configure script is always odd---that 
least-significant bit will be dropped when the script is unpacked on a 
filesystem with 2-second timestamp resolution.

If stat from GNU coreutils is not available, fall back to the current 
sleep(1)-based test and just eat the delay in the name of portability.  
The test checks only for "coreutils" because very old versions did not 
say GNU.  A better, functional test for stat(1) is probably also possible.


-- Jacob