`true` startup is slower than `gnutrue` startup

Edit: I narrowed down the problem to uutils multi-call binary startup in general. Testing ./coreutils true vs gnutrue is a more minimal example.

Original report about ls and gnuls:

Someone subtly criticized Ubuntu's adoption of uutils, saying it was slower, despite me saying Rust is supposed to be faster.

For an ls of an empty directory, coreutils ls is much faster: perf stat -r 200 -e cycles,task-clock -- uu-ls /tmp/empty/ >/dev/null, on my i7-6700k Skylake at ~3.9GHz, uu-ls averaged about 2.0ms per invocation, Coreutils ls about 0.5ms. So about 1.5 ms less startup overhead, assuming the actual work takes no or equal time. (With a small directory like 10 files and a couple subdirs, they each take incrementally about the same amount more time, about 0.05 ms more, very roughly with noisy measurements, but repeating many times to warm up CPU to max MHz.) – Peter Cordes Commented

I tested an empty directory at /mnt.

Expected behavior

See GNU coreutils' ls' performance.

home@daniel-desktop3:~$ perf stat -r 200 -e cycles,task-clock -- /bin/gnuls /mnt >/dev/null

 Performance counter stats for '/bin/gnuls /mnt' (200 runs):

         2 162 945      cycles                           #    4,299 GHz                         ( +-  0,28% )
              0,50 msec task-clock                       #    0,624 CPUs utilized               ( +-  1,10% )

         0,0008064 +- 0,0000108 seconds time elapsed  ( +-  1,33% )

Actual behavior

uutils Ubuntu 25.10 is 120% slower. uutils 0f891cc66f5bee12ed3217000afd6ac4c07247aa is 108% slower. Peter Cordes said an unknown version was 300% slower.

home@daniel-desktop3:~$ /home/home/CLionProjects/uutils/target/release/coreutils ls --version
ls (uutils coreutils) 0.7.0
home@daniel-desktop3:~$ perf stat -r 200 -e cycles,task-clock -- /home/home/CLionProjects/uutils/target/release/coreutils ls /mnt >/dev/null

 Performance counter stats for '/home/home/CLionProjects/uutils/target/release/coreutils ls /mnt' (200 runs):

         5 770 027      cycles                           #    4,329 GHz                         ( +-  0,19% )
              1,33 msec task-clock                       #    0,751 CPUs utilized               ( +-  0,85% )

         0,0017746 +- 0,0000160 seconds time elapsed  ( +-  0,90% )
home@daniel-desktop3:~$ /bin/ls --version
/bin/ls (uutils coreutils) 0.2.2
home@daniel-desktop3:~$ perf stat -r 200 -e cycles,task-clock -- /bin/ls /mnt >/dev/null

 Performance counter stats for '/bin/ls /mnt' (200 runs):

         6 725 333      cycles                           #    4,635 GHz                         ( +-  0,17% )
              1,45 msec task-clock                       #    0,785 CPUs utilized               ( +-  0,77% )

         0,0018475 +- 0,0000146 seconds time elapsed  ( +-  0,79% )

Start with the uutils multi-call binary startup path, using the issue's minimal comparison of ./coreutils true and gnutrue rather than the original ls example. Reproduce the timings with perf stat -r 200, then identify and reduce the startup overhead so the multi-call binary is closer to GNU coreutils performance.