This page contains benchmarks of linking various programs. The benchmarks are just running the linker, not the compiler. All benchmarks are run on an AMD Ryzen 9 9955HX 16-Core (32 thread) processor with 92GiB of RAM. The output file is always on tmpfs.
For benchmarks run on David's 2020 era laptop which were used in benchmark reports prior to 2026, see lemp9.md.
The benchmarks include several other linkers for Linux as well as several recent versions of Wild. This allows us to both compare between linkers and to see how Wild's performance is changing over time.
We only include GNU ld (BFD) in a few of the benchmarks since it's generally a lot slower than the other linkers and including it messes up the scaling on the charts. It does do OK on memory consumption though.
The little white ticks on each bar are 99% confidence intervals and show how accurate we think our mean value is. i.e. if we reran the benchmark 100 times, we'd expect that 99 times we'd get a mean within that the range of the white tick.
We start with linking the Chrome web browser (technically Chromium). This is a very large codebase and a pretty large binary.
CREL relocations are a new format for relocations that is significantly more compact. Wild has supported these for a couple of releases, however we hadn't benchmarked non-trivial programs with CREL relocations until just prior to the 0.8.0 release. It turned out that we had a bug that caused memory usage to blow up, making it impractical to link non-trivial programs. This is now fixed, so we benchmark CREL relocations from 0.8.0. Chrome uses CREL relocations by default.
For a smaller CREL benchmark, we link Mold, with the compiler configured to emit CREL relocations (not the default configuration).
Clang with debug info has massive quantities of debug strings that need to be deduplicated. So link time here is dominated by how quickly we can deduplicate strings.
This benchmark is the same as the previous one, but with the extra flag --strip-debug. It shows to
what extent linkers are able to take advantage of the fact that they don't need to emit the debug
info that's in the input files.
Rustc is quite large. Most of the code however goes into librustc-driver. Rustc itself it pretty quick to link, so we only benchmark linking of librustc-driver.
Ripgrep is a popular grep alternative. It's got a pretty lean dependency tree, so is fairly fast to link.
Wild linking itself.
Wild linking a risc-v version of itself. We're still doing the linking on x86_64, but the binary being produced is for risc-v.
Wild linking itself with linker-plugin LTO. This is much much slower, since the linker plugin ends up doing heaps of work during linking.
Now a couple of trivial, hello-world programs. One written in Rust and one written in C.
We care not just about execution time, but also memory consumption. Here are the same benchmarks as above repeated, but this time measuring the peak memory consumption of the linkers.
