On Fri, Mar 6, 2026, at 11:53 AM, Ross Burton wrote: > Testing the time to autoreconf+configure gettext, my pathological > test case, I see autoconf 2.72.90 is noticeably slower: > > autoconf 2.72: 0:02:38 gettext:do_configure > > autoconf 2.72.90: 0:03:12 gettext:do_configure
I don't see a difference this large, but I do see something interesting. I instrumented all of the configure scripts in this package using the PS4 trick described in <https://stackoverflow.com/a/5015179> and then added up the time spent executing each individual command. With 2.72: program total.secs 1 gcc 85.9 2 conftest 13.8 3 g++ 4.34 4 rm 3.91 5 cat 3.86 6 case 3.66 7 sed 3.65 8 grep 1.37 9 printf 1.28 10 let 1.22 ("let" is variable assignment.) As you would expect, the lion's share of the time is spent executing the C and C++ compilers and test programs. With 2.73, that's still true, but ancillary data- shuffling commands take more time by a small but significant amount: program total.secs 1 gcc 85.9 2 conftest 13.8 3 cat 5.05 4 g++ 4.35 5 rm 3.95 6 case 3.68 7 sed 3.66 8 grep 1.38 9 printf 1.28 10 let 1.22 Notice how "cat" has taken the third place away from g++. All of the executions of "cat" that take significant time are from this construct cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ // ... test program here ... _ACEOF which occurs for every test program we need to feed to the compiler. With both 2.72 and 2.73, there are 1550 executions of "cat" that take more than a millisecond, but with 2.72 they add up to 2.81 seconds and with 2.73 they add up to 3.98 seconds. 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? Regardless, changing how we feed test programs to the compiler would be much too risky for 2.73, and I am honestly at a loss for alternatives, given how constrained truly portable shell programming is. I would be very interested to see profiling results from your computer, particularly if you can dig deeper than just per-command wall-clock timings (maybe with whole-system 'perf'?) zw p.s. Because gettext makes such heavy use of subdirectory configure scripts, you can substantially speed up configuration of the whole package by adding --config-cache=$(pwd)/config.cache to the top-level configure command line. The cache mechanism is off by default because it's unreliable across packages or across long periods of time (e.g. nothing flushes the cache when the compiler has been updated) but _within a single source tree_ that's all being configured at once it should be safe to use.
