uutils 0.12 vs GNU coreutils 9.12 benchmark: Rust tools slower in 91 of 157 cases, 2.8x on startup

A new benchmark pits the Rust rewrite of the Unix core utilities against the incumbent and comes back with a split verdict: for most commands the two behave identically, but the Rust versions lose on speed more often than they win, and launching a process costs nearly three times as much.

The comparison, published on dev.to by efraingaray, matched uutils coreutils 0.12 against GNU coreutils 9.12. All measurements ran inside containers operating under resource limits, across three dimensions: the complete GNU test suite, byte-for-byte output comparisons covering 157 commands, and process startup timing.

Where the numbers land

On raw speed, GNU came out ahead more often than not. According to the benchmark, uutils was the slower option in 91 of the 157 measurement cells — about 58 percent — while the remaining 66 went to uutils or ended level. The dev.to post is a summary; the command-by-command matrix showing exactly which utilities each side wins on sits in a longer write-up on the author's own site, together with a verdict on whether uutils is ready to stand in for GNU on a real machine.

On behavior, the headline conclusion is encouraging for the rewrite: the large majority of compared commands produced identical output, which is precisely what a drop-in replacement has to achieve. One exception is called out explicitly.

The 2.8x startup penalty

The most lopsided result involves process creation. Spawning 5,000 processes under uutils took 2.8 times longer than under GNU coreutils. The summary offers no diagnosis, so whether the cause is binary size, linking strategy, runtime initialization or something else remains unstated.

The number matters because of how these tools are actually used. Shell scripts, build systems and package managers invoke coreutils commands in rapid succession, and each invocation typically does a sliver of work before exiting. In that regime, fixed startup cost can dominate total runtime, and a per-spawn penalty approaching 3x compounds across the thousands of calls that make up a single build or package install.

A divergence in mv

The benchmark also flags a correctness gap: when mv moves a file between disks, the resulting file loses its timestamps. A move across filesystems cannot be handled as a simple rename, so the tool has to copy and then delete; on that path, uutils drops the original file's time metadata. For anything that relies on mtimes — build systems and backup tools are the classic cases — a silent metadata change is arguably more disruptive than a slowdown.

Why it matters

uutils is the most prominent effort to date to rebuild the GNU coreutils — the ls, cp, mv and cat family of utilities that sit at the base of nearly every Linux system — in Rust, a language whose memory-safety guarantees address a class of bugs that C implementations always carry some risk of. Whether it can actually replace GNU depends on exactly the kind of evidence this benchmark supplies: functional parity across most commands is the prerequisite, and by the author's account uutils largely clears it. What remains is narrower and more concrete — a startup tax that punishes script-heavy workloads, and at least one behavioral gap in mv — and now those gaps have numbers attached. For maintainers weighing a switch, that converts a question of impressions into an engineering trade-off: does a given deployment's tolerance for slower process churn and edge-case metadata differences outweigh the safety argument for the rewrite?