mold 2.42: A Parallel Linker That Cuts Debug Rebuilds to Seconds

The Problem: Linking Is the Serial Bottleneck in Builds

The README frames the problem in terms of developer productivity, but the practical pain is concrete: a 50-second link for TensorFlow or a 16-second link for Chromium breaks concentration. mold's pitch is that those numbers drop to 3.15 seconds and 1.65 seconds respectively on a 64-core Threadripper, based on the August 2026 benchmark table. That is the kind of claim that matters to an engineer who has stared at a spinner for two minutes.

Why mold Is Fast: Massively Parallel Linking

The design trade-off is that mold achieves this by using more memory and more threads. The README does not list memory usage numbers, but a linker that parallelizes aggressively will consume more RAM than a serial one. For a 9.55 GiB output like TensorFlow, that could be a real constraint on a developer laptop. The documentation does not address this directly, so a team adopting mold should check their available memory before assuming the speedup is free.

Benchmarks: Where mold Wins and Where It Does Not

The release-build rows on the M1 Ultra show even smaller gaps. For Blender release, mold is 0.25 seconds versus lld's 0.56 seconds, a 2.3x gain, but wild is 0.20 seconds, so mold loses to wild. For Clang release, mold and wild tie at 0.14 seconds. The pattern is that mold's advantage over lld is consistent, but its advantage over wild is not. The README states that mold links 4.9x faster than lld and 1.9x faster than wild at the median across all benchmark rows, but the median hides the cases where wild wins. An engineer who only cares about one specific binary should look at the row for that binary, not the median.

Getting Started: Installation and Basic Usage

One caveat: the benchmark table includes ARM64 rows for Chromium and Firefox, and those rows show mold working on ARM64 Linux. But the M1 Ultra runs Fedora Asahi Remix, which is Linux on Apple silicon, not macOS. mold is a Unix linker, and the README does not claim macOS support. If you are on macOS, you cannot use mold as a drop-in replacement for the system linker; you would need to run Linux in a VM or container, which defeats the purpose of speeding up local builds. That is a hard limitation that the README does not explicitly state, but it is implied by the benchmark environment.

A Real Limitation: wild and Identical Code Folding

The practical failure mode is that a build system which works with lld may not work with mold if it relies on linker behaviors that mold implements differently. The README does not list specific incompatibilities, but the existence of N/A rows for wild shows that linkers differ in feature support. For mold, the risk is that it is a from-scratch implementation, and subtle differences in how it handles symbol resolution, section ordering, or garbage collection could produce a binary that behaves differently at runtime. The README claims mold is in production use since 2021 and is the default linker of many large open-source projects, which suggests those differences are rare, but it is not a guarantee. A team adopting mold should run their test suite on a mold-linked binary before trusting it in production.

Maintenance and Upgrade Cost

The upgrade risk is that a new version might change linker behavior, which could affect your build output. The README does not include a changelog in the provided material, so it is impossible to know what changed between v2.40.4 and v2.42.0. A cautious team would pin the version they use in CI and test a new release before rolling it out. The fact that mold is a from-scratch implementation means that bug fixes are frequent, but also that new features might introduce regressions. The MIT license does not come with support, so you are responsible for testing upgrades yourself.

Alternatives: lld and wild

The choice between mold and wild depends on your build. If you need ICF or other advanced features, mold is the only viable alternative to lld. If you have a simpler build that does not use ICF, wild might be worth trying, especially on ARM64 where it beat mold on Clang debug. But the README's own benchmark shows mold is faster than wild on most large programs, so the default recommendation for speed is mold.

Editorial conclusion

Adopt mold if you build large C, C++, or Rust binaries on x86-64 Linux and the link phase dominates your debug cycle; the benchmark table shows the biggest wins on big outputs like Chromium and TensorFlow. Avoid it if you need macOS support (the benchmarks only cover Linux on Apple silicon) or if your team relies on wild's `--icf=all` behavior, since mold's identical code folding may differ. Before switching, verify that every linker flag in your build system is supported by mold, and test that the output binaries run correctly, because a faster link that produces a subtly different binary is not a win.

Official sources

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