mold's 4.9x over lld holds on a Threadripper and thins on an M1 Ultra

The 4.9x median is a many-core result, and the M1 rows disagree

The headline number is 4.9 times faster than lld and 1.9 times faster than wild at the median, and it is accurate as stated. The tables underneath are where the decision gets made. On a 64-core Threadripper linking debug builds, Chromium 145 goes from 16.64 seconds with lld to 1.65 with mold, and TensorFlow 2.21 goes from 50.73 seconds to 3.15, which is sixteen times. On an M1 Ultra the margins narrow. Blender 5.2 debug takes 1.56 seconds against wild's 1.81, a modest win, and Clang 21 debug takes 2.96 seconds against wild's 2.78, which is mold losing. In the M1 release table, Blender is 0.25 against 0.20 and Clang is 0.14 against wild's 0.15, listed as 1.0x. The file frames the two machines as a many-core workstation on one side and a high-performance desktop on the other, and the split in the numbers follows that frame exactly.

Debug builds are where the win is, because the output is ten times bigger

Look at the output sizes in the table rather than the ratios. Chromium's debug output is 4.51 GiB and its release output is 0.58 GiB. TensorFlow's is 9.55 GiB against 0.73 GiB. The linker's work scales with the size of what it is combining, so a debug configuration that emits an enormous binary is the case where a faster linker changes your day, and the same project in release mode gets a fraction of the benefit. That is also why the file frames the whole thing around the debug-edit-rebuild cycle. Worth knowing when you read the numbers: the three linkers were built from source in release configuration as of 2026-08-28, ran with default options, and the times are wall-clock as the caller sees them, the median of three runs after a warm-up. These are clean measurements of the tools, not of a tuned configuration.

An N/A in the table means the linker cannot do the job at all

The wild column is full of N/A entries, and the file explains what they mean: N/A indicates that the linker cannot link that program. Chromium release is a separate case: wild's links there are also marked N/A because wild does not implement --icf=all and links without identical code folding. This is a feature difference wearing a performance table's clothing, and it changes how you should read the comparison. A linker that is faster on the rows it supports and absent from the others is not slower, it is out of scope for that program. So when you are choosing, the coverage question comes before the speed question: if your build needs identical code folding, wild is not an option whatever its numbers say, and part of mold's margin over it is a capability rather than an implementation trick.

Twenty targets, one crate each, and a dispatcher binary

The Cargo manifest explains an unusual build layout. The linker is generic over the target, and the comment above the workspace section says that instantiating it for all twenty targets in one crate keeps the compiler on a single core for minutes, so each target is instantiated in a crate of its own under arch/, and the executable in cli/ dispatches to them. The workspace members are cli, common, elf, macho, arch/* and tests. The practical effect is on your build of the tool rather than on your build of the project: the split exists so the per-target work is not a single-core compile of one crate. Note that the two documents count targets differently, since the file lists eleven architecture families from x86-64 through SH-4 while the manifest comment says twenty targets.

The dependency list is the design in miniature

The manifest's workspace dependencies show the layout directly. Next to libc, they list mold-common, mold-elf and one crate per target, such as mold-elf-x86_64, mold-elf-arm64, mold-elf-riscv64 and mold-elf-s390x, each pinned to exactly =3.0.0. A comment explains why: the workspace crates are published together and depend on each other's internals, so each one requires the exact version of the others.

Panics abort in release, and the tests are a separate workspace member

The tests directory is listed as its own workspace member. The workspace package block sets version 3.0.0, edition 2024 and rust-version 1.95, and the tree carries a rust-toolchain.toml and a rustfmt.toml, which together mean the toolchain and the formatting are decided by the repository rather than by your shell. At the top level there are also dist.sh, install-mold.sh, install-test-deps.sh, and a docs directory, so packaging and installation live next to the source.

A drop-in replacement for Unix linkers, in production since 2021

mold is written by the original developer of LLVM lld, the linker that Android, Chrome, FreeBSD, PlayStation, Nintendo Switch and other production systems are built with. The project describes itself as an effort to build an even faster linker from scratch, free of the architectural limits its author ran into while optimising lld, which is a more interesting origin than a from-scratch linker usually has: the design constraints are the ones a maintainer of the incumbent actually hit. It has been in production use since 2021 and is described as the default linker of many large open-source projects. Two boundaries are worth naming before you plan an adoption. It is a drop-in replacement for Unix linkers, so a Windows toolchain is outside what the file describes.

Editorial conclusion

mold fits a project whose debug link step is measured in seconds, which is precisely the debug-edit-rebuild cycle it was written for, and the size of your link output tells you whether you are in that group. It does not fit a small-output build, where the win is a fraction of a second, and the median headline hides a second boundary, because on the M1 Ultra wild beats mold on two rows. Before you switch, check three things. That your toolchain can use a Unix linker, since the file describes a drop-in replacement for Unix linkers and says nothing about Windows. That your project does not need a capability another linker lacks, since a row marked N/A in those tables means the linker cannot link that program at all. And that you can accept a Rust build for the tool, with one crate per target under arch/.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes