On 5/13/26 11:53 PM, debianyu wrote:

In an interactive shell, executing a fork-heavy loop with command substitution 
twice consecutively exhibits a ~2.5x slowdown on the second and subsequent runs:

time for i in {1..10000}; do echo $(date) >/dev/null; done   # ~16s
time for i in {1..10000}; do echo $(date) >/dev/null; done   # ~40s
time for i in {1..10000}; do echo $(date) >/dev/null; done   # ~40s

The slowdown persists for the shell's lifetime, including subshells spawned 
from it.

Bisecting build configurations and bash versions reveals the slowdown requires 
both:

Bash 5.x series (5.0 onward; 4.4 unaffected)
./configure --with-bash-malloc=no (bash uses glibc malloc)

Either condition alone does not trigger the issue:

That's interesting. I haven't seen the glibc malloc trigger such a dramatic
slowdown before.

Trigger Condition: Loop body must involve both fork and execve. Builtins or 
fork-only operations (e.g., x=$(:)) do not trigger the issue.

I agree that the patch in

https://lists.gnu.org/archive/html/bug-bash/2026-05/msg00038.html

is worth looking at.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    [email protected]    http://tiswww.cwru.edu/~chet/

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to