mold linker paper claims sub-second links of multi-gigabyte debug binaries

The linker — the tool that stitches compiled object files into executables and shared libraries — rarely gets attention until it starts costing real time. A paper describing mold, a Unix/Linux linker designed for parallel execution from the ground up, reached Hacker News's front page on August 26, two days after the preprint was submitted to arXiv by Rui Ueyama on August 24, 2026. Its results suggest that for large C++ projects, link times can shrink by an order of magnitude or more.

What the paper reports

According to the paper, mold links multi-gigabyte debug builds — the kind large C++ programs produce when compiled with full symbol information — in at most a few seconds, and often in under a second. Measured against the modern lld linker, mold comes out 2.4 to 16.1 times faster on the tested programs. Against GNU ld, the traditional linker in the GNU toolchain, the reported gap widens to as much as 112x.

Why existing linkers don't scale

The paper's diagnosis is architectural rather than incidental. Symbol resolution — matching every reference in a program to the definition that satisfies it — has historically been interwoven with archive processing, the logic that decides which object files to extract from static libraries. Because each extracted object can introduce new unresolved symbols that demand further extraction, the linker is pushed into a dependency-driven sequence that resists being split across cores. Among the constraints the paper identifies, this coupling is what leaves most CPU cores idle while a link runs.

A clean-slate design

mold's answer is to start over rather than optimize incrementally. The paper describes a design that decouples symbol resolution from archive handling, breaking the sequential chain, and then applies data parallelism systematically across every stage of the linking pipeline instead of a few hot spots. The framing matters: concurrency is treated as a structural requirement of the architecture from the outset, not a retrofit bolted onto a sequential core.

No single fix dominates

An ablation study in the paper probes which of mold's optimizations contribute most to the overall speedup. The finding is that none dominates on its own — the gains come from the cumulative effect of parallelizing all passes. That result reinforces the paper's central claim: partial parallelism leaves sequential remnants that cap total throughput, so it is the architecture, not any individual trick, that delivers the performance.

Why it matters

For developers on large C++ codebases, the linker is frequently the last serial choke point in the edit-compile-debug loop. Compilation parallelizes across cores and machines, but the final link has traditionally run as one long sequential operation — and debug builds make it worse, since full symbol information can push binaries to multiple gigabytes. If mold's numbers hold up outside its authors' benchmarks, switching linkers becomes one of the cheapest build optimizations available: no source changes, just a faster tool at the end of the pipeline. That matters most for workflows that re-link constantly, such as incremental test runs, sanitizer and debug configurations, and CI jobs that link each variant separately. Two caveats are worth keeping in mind: the figures are the paper's own measurements rather than independent evaluations, and mold targets Unix/Linux, so the paper makes no claims about macOS or Windows binaries.