Link Speed 40x Faster? How mold Redefines the Modern Linker

mold: A Modern Linker That Makes Linking Fly 🦠

As a Java veteran who's been tortured by the Spring ecosystem for years, I rarely touch low-level tooling. But today's mold project made even me, an "upper-layer application developer," want to chat about it—because it solves a pain point every compiled language developer faces: linking is too slow.

What's a Linker? Why Should You Care About Its Speed?

Simply put, when you write code in C, C++, or Rust, the build process has two steps:

1. The compiler translates source code into .o object files
2. The linker packages these object files into the final executable or shared library

Everyone's familiar with step one, but step two is often the hidden bottleneck. Imagine compiling hundreds of source files, only to get stuck at the final step waiting for the linker to work its "leisurely" magic—that kind of waiting kills developer enthusiasm fastest. The mold author puts it bluntly: it wants developers to wait less in the "debug-edit-rebuild" cycle.

Just How Insane Is the Performance?

The README provides several comparison datasets, and I was genuinely shocked after reading them:

mold is 3-4x faster than the second-fastest lld and dozens of times faster than traditional GNU ld. The author even added a punchline: mold is only 2x slower than the cp command. This isn't optimization anymore; this is a dimensional strike.

Core Technology: Why Is mold So Fast?

According to the documentation, mold's secrets come down to two main points:

1. More Efficient Algorithms and Data Structures

Traditional linkers may not have considered modern hardware characteristics during design. mold redesigned data processing from the ground up. It's like swapping an old green train for a high-speed rail—the tracks are the same, but the efficiency difference is night and day.

2. Extreme Parallelization

This is the key. The author included a CPU utilization comparison chart: lld on the left, mold on the right. lld's bar graph is choppy with underutilized cores, while mold maxes out all 16 cores from start to finish.

This reminds me of thread pool tuning in my Java projects—many tools have overly conservative default configurations that never leverage multi-core advantages. mold goes the opposite direction: if it can be parallelized, it won't be serialized. That's why it takes off on a 16-core, 32-thread machine.

Installation and Usage: Truly "Brainless Replacement"

mold positions itself as a "drop-in replacement," meaning seamless substitution for existing linkers. You don't need to change code or even build scripts—just tell the compiler "use mold instead of ld."

Installation (Source Compilation Example)

git clone --branch stable https://github.com/rui314/mold.git
cd mold
./install-build-deps.sh
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_COMPILER=c++ -B build
cmake --build build -j$(nproc)
sudo cmake --build build --target install

Note: Requires a C++20 compiler, GCC 10.2+ or Clang 16.0+ recommended. If your system is too old, the author provides a Podman container build solution—just run ./dist.sh to generate a packaged tar file. Hassle-free.

Usage (The Core!)

For Clang users:

clang -fuse-ld=mold your_code.cpp -o your_program

For GCC 12.1+ users:

gcc -fuse-ld=mold your_code.cpp -o your_program

For older GCC users (before 12.1, -fuse-ld=mold isn't recognized):

gcc -B/usr/libexec/mold your_code.cpp -o your_program

Here's a pitfall: the -B option in older GCC tells it where to find the ld command. After installing mold, there's an ld symlink under /usr/libexec/mold or /usr/local/libexec/mold pointing to mold itself.

Rust Project Configuration

Rust developers need to add this to .cargo/config.toml:

[target.'cfg(target_os = "linux")']
linker = "clang"
rustflags = ["-C", "link-arg=-fuse-ld=/path/to/mold"]

Using clang as the linker driver here because it always accepts the -fuse-ld option. If you want global effect, just add this to ~/.cargo/config.toml.

Lazy Mode: mold -run

If you're too lazy to modify build scripts, or the build system is too complex to figure out where to start, use mold's LD_PRELOAD interception mode:

mold -run make -j$(nproc)

The principle: mold injects a shared object via LD_PRELOAD, intercepting all exec(3) series function calls, replacing commands like ld, ld.bfd, ld.gold, ld.lld with mold itself. This trick truly delivers "acceleration without modifying a single line of code."

Verify You're Actually Using mold

readelf -p .comment <executable-file>

If the output contains mold plus a version string, you're successful:

String dump of section '.comment':
  [     0]  GCC: (Ubuntu 10.2.0-5ubuntu1~20.04) 10.2.0
  [    2b]  mold 9a1679b47d9b22012ec7dfbda97c8983956716f7

Architecture Support: Not Just x86

mold's supported architecture list opened my eyes as someone who's only touched x86 and ARM: x86-64, i386, ARM64, ARM32, RISC-V (both endianness), PowerPC (ELFv1/ELFv2), s390x, LoongArch, SPARC64, m68k, SH-4... It basically covers mainstream and niche architectures alike. This shows the author genuinely wants to make mold a universal solution, not just serve a specific platform.

Comparison with Similar Tools

lld is already the "speed champion" in the LLVM ecosystem, but mold is still 3-4x faster. Objectively speaking, lld's advantage lies in deep integration with the LLVM toolchain, while mold currently leans more toward an "independent tool" positioning.

Personal Opinion: Is It Worth Using?

My take: Absolutely worth it, with conditions.

If you:

• Develop in C/C++/Rust with large-scale projects (link output over hundreds of MB)
• Frequently do "modify-compile-test" iterations locally
• Use a newer Linux distribution (mold available in package manager)

Then mold should save you significant waiting time daily. Especially for large projects, shrinking from 40 seconds to 1 second—that experience improvement is very real.

But watch out for these pitfalls:

1. Older GCC versions need the -B option, can't use -fuse-ld=mold directly
2. Some special scenarios (like embedded cross-compilation) may need extra configuration
3. Although the author claims seamless replacement, always thoroughly test before swapping core toolchains in production

As an 8-year backend developer, I don't directly invoke linkers usually, but this project's design philosophy really inspired me: even low-level infrastructure has huge optimization potential. Often we get used to "tools are just this slow," but really we just haven't met someone who squeezes every drop of performance.

mold's author rui314 is exactly that kind of person—he previously wrote an optimized lld version and now works full-time on mold. The project survives on GitHub Sponsors, which makes us "free-riding" developers should pay more attention to and support such infrastructure projects.

Final Summary: mold is a rare high-performance toolchain project in recent years, redefining linker performance benchmarks with modern C++ and parallelization technology. If you've been tortured by compile waiting, give it a try—after all, who can refuse turning 40 seconds of waiting into 1 second?