[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#53951] [PATCH] m4: speed up filesystem modification checks
From: |
Jim Meyering |
Subject: |
[bug#53951] [PATCH] m4: speed up filesystem modification checks |
Date: |
Sat, 12 Feb 2022 13:51:01 -0800 |
On Sat, Feb 12, 2022 at 2:07 AM Mike Frysinger <vapier@gentoo.org> 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.