deniz.in

Markets

Weather

Loading weather

· via dev.to (home feed)

Wild 0.10.0 beats mold in all 20 Rust linking runs as link time falls to about 1% of rebuild

Benchmarks on dev.to show Wild 0.10.0 out-linking mold 2.42.1, rust-lld and GNU ld on ripgrep and cargo in every run, with linking down to roughly 1% of a full rebuild.

Wild 0.10.0 beats mold in all 20 Rust linking runs as link time falls to about 1% of rebuild

What was measured

A developer writing on dev.to under the handle efraingaray has published linker benchmarks comparing four tools on real Rust code: Wild 0.10.0, mold 2.42.1, rust-lld and GNU ld. The workloads were ripgrep and cargo, and each configuration was run 20 times per project to smooth out variance.

Wild is a comparatively new linker written in Rust that competes with mold and lld on raw link speed. mold has been a popular way to cut build times since it appeared, and rust-lld ships with Rust toolchains as a faster alternative to GNU ld. The benchmark asks whether Wild can now hold its own against the established options.

The results

According to the dev.to post, Wild came first in every one of the 20 runs for each project. The margins were small in absolute terms — 1.9 ms on one project and roughly 8 ms on the other — but they held across every repetition, and consistency over 20 runs is a stronger signal than the size of a single-run gap.

The second finding may matter more than the ranking itself. With either fast linker in the chain, the post reports that linking accounted for close to 1% of total rebuild time on the tested projects. At that share, the link step no longer sets the pace of a rebuild: compilation and earlier build stages dominate, and shaving further milliseconds off linking would barely register in end-to-end build times.

A near miss with the numbers

The author also discloses that the results nearly went out wrong. The write-up documents the trap that produced the false initial figures and how it was caught before publication, though the dev.to summary does not spell out exactly what went wrong. The full measurements sit in a longer post on the author's own blog.

Even without the specifics, the episode underlines how easy it is to get linker benchmarks wrong. Warm file-system caches, leftovers from incremental builds and timing artifacts can all distort results, and a comparison that looks decisive can end up measuring the wrong thing entirely.

Why it matters

Link time is a fixed cost paid on every rebuild, so it sits squarely in the inner loop of development. For Rust in particular, where long compile times are a recurring complaint, linking has been one of the few places where simply swapping a tool could buy an immediate win — which is why mold and lld gained traction in the first place.

These numbers suggest two things. First, Wild has matured: a version that consistently edges out mold across every measured run indicates that a Rust-native linker is now a practical choice rather than an experiment. Second, and more sobering for anyone hoping for further build-time gains from linkers, the headroom is nearly exhausted for projects of this size. When linking sits around 1% of a rebuild, the remaining time is spent in the compiler, so the next meaningful improvements will have to come from rustc, dependency handling or build structure — not from a faster linker.

One caveat is worth keeping in mind: the benchmark covers two projects on one machine, and a 1.9 to 8 ms gap is well within the range that different hardware, larger binaries or heavier link features such as debug info could reorder. The direction of the result is nonetheless clear: fast linkers have done their job, and the bottleneck has moved on.

  • #rust
  • #linker
  • #build-tools
  • #benchmarks
  • #developer-tools

Related posts