uutils has more overhead [LWN.net]

uutils has more overhead

Posted Oct 24, 2025 11:09 UTC (Fri) by pixelbeat (guest, #7440)
In reply to: uutils is doing well, but needs to be carefully managed by Keith.S.Thompson
Parent article: Date bug affects Ubuntu 25.10 automatic updates

Interesting, I hadn't realized /bin/true was still GNU. Perhaps this is a performance consideration, as all uutils have a larger startup overhead than their GNU equivalents, due mainly to the large multicall binary being used (due to rust binaries being significantly larger). For example:

$ time seq 10000 | xargs -n1 true
real	0m8.634s
user	0m3.178s
sys	0m5.616s

$ time seq 10000 | xargs -n1 uu_true
real	0m22.137s
user	0m6.542s
sys	0m15.561s

It irks me to see mention of rust implementations being faster, when at a fundamental level like this they're slower and add significant overhead to every command run

to post comments

uutils has more overhead

Posted Oct 24, 2025 13:41 UTC (Fri) by ebee_matteo (guest, #165284) [Link] (2 responses)

From https://github.com/uutils/coreutils:

> If you don't want to build the multicall binary and would prefer to build the utilities as individual binaries, that is also possible.

This is a decision from the distribution to take, I would say.

uutils has more overhead

Posted Oct 24, 2025 13:55 UTC (Fri) by pixelbeat (guest, #7440) [Link] (1 responses)

Yes agreed, though it's a different decision with uutils as the separate binaries are significantly larger.

Note also that GNU coreutils can be built as a multi-call binary. Testing the performance of that here shows that the overhead is not rust specific, but rather the dynamic linker overhead loading the full set of libs linked by the multi-call binaries

$ ./configure --enable-single-binary --quiet && make -n $(nproc)

$ time seq 10000 | xargs -n1 src/true

real	0m21.595s
user	0m7.437s
sys	0m14.151s

uutils has more overhead

Posted Oct 25, 2025 8:26 UTC (Sat) by ebee_matteo (guest, #165284) [Link]

I agree, but it should be noted that the main reason the binaries are larger is linked to compilation flags around panic behavior (abort vs. unwind), and the fact that the stdlib is built with the generic use case in mind, and as such contains verbose backtrackes and error printing which inflate the final binary size.

I still think that this is a decision for the distribution. It's a tradeoff between being able to better debug and diagnose issues, and binary size.

If I try to use a recompiled version of Rust stdlib and panic = abort, for many binaries I get comparable sizes to the GNU version (not all, this is true, but some of them also add some features).