[bug#53951] [PATCH] m4: speed up filesystem modification checks

On Sat, Feb 12, 2022 at 2:07 AM Mike Frysinger <[email protected]> wrote:
> The current code sleeps at least 1 second to make sure the generated
> files are strictly newer than the source files.  It does this for a
> few reasons: POSIX only guarantees that `sleep` accept integers, and
> filesystems have a history (c.f. Windows) of bad timestamp resolution.
>
> For the first part, we can easily probe sleep to see if it accepts a
> decimal number with a fractional part -- just run `sleep 0.001`.
>
> For the second part, we can create two files and then run sleep in a
> loop to see when one is considered newer than the other.
>
> For many projects, this 1 second delay is largely amortized by the
> rest of the configure script.  Autoconf lends itself to being both
> large & slow.  But in projects with many smallish configure scripts
> with many cached vars, the time to rerun is dominated by this single
> sleep call.  For example, building libgloss against a compiler with
> many (60+) multilib configurations, we see:
> [Using sleep 1]
> $ time ./config.status
> real    2m28.164s
> user    0m33.651s
> sys     0m9.083s
> [Using sleep 0.1]
> $ time ./config.status
> real    0m39.569s
> user    0m33.517s
> sys     0m8.969s
>
> And in case anyone wonders, going below 0.1s doesn't seem to make a
> statistically significant difference, at least in this configuration.
> It appears to be within "noise" limits.
> [Using sleep 0.001]
> $ time ./config.status
> real    0m39.760s
> user    0m33.342s
> sys     0m9.080s
>
> * m4/sanity.m4: Determine whether `sleep` accepts fractional seconds.
> Determine (roughly) the filesystem timestamp resolution.  Use this to
> sleep less when waiting for generated file timestamps to update.

Nice work. I looked through the patch and didn't see any issue.