On Wed, Mar 18, 2026, at 12:46 PM, Paul Eggert wrote: > On 2026-03-18 09:22, Zack Weinberg wrote: >> I don't have a good explanation for this; it seems to me that even >> for the longest test programs we have, that construct should never >> take more than a few _micro_seconds. Maybe bash implements it in an >> inefficient way? > > Perhaps PATH is long and 'cat' is late in the PATH? > > If Autoconf 2.73 prepends stuff to PATH that 2.72 didn't, that might > at least partly explain the small increase that you observe.
My PATH _is_ pretty long and 'cat' _is_ near the end of it, but neither version of the configure script _modifies_ PATH, and bash's cache of where programs are found should mean that 'cat's location within PATH doesn't matter. I'm currently looking into the possibility that the 'copy_file_range' system call is inefficient for small files: the attached shell script mimics the `cat confdefs.h - <<heredoc` pattern and strace tells me it spends 3.61% of its runtime in 'copy_file_range' vs. only 2.25% in 'read'+'write', despite having to move approximately 12x more data through 'read' and 'write'. (This test also lets me confirm that current versions of bash and dash aren't doing anything super inefficient like reading from the script one character at a time or writing out heredocs one line at a time, both of which I vaguely recall being a problem a long time ago.) Do you happen to remember why we concatenate confdefs.h and the test program, instead of #include-ing confdefs.h from the test program? zw
slow-heredocs-maybe.sh
Description: application/shellscript
