Rust Logo Rust Programming Language - Performance and Safety Combined

Rust Compile Time Optimization: Why is Your Compilation So Slow?

Every time you write Rust code, are you staring at the cargo build progress bar? Long compile times are a common problem faced by many Rust developers, especially in large projects.

Let’s be honest: what’s the most painful part of writing Rust? It’s not ownership or lifetimes. It’s changing one line of code and then staring at cargo build spinning around until you question your life choices.

Compilation Waiting Every code change requires waiting for compilation to complete

I had a project with hundreds of thousands of lines of code that took 22 minutes for a full compile. What does 22 minutes mean? That’s enough time to brew coffee, scroll through your social media feed, take a bathroom break, and come back—only to find it’s still compiling. Incremental builds also took several minutes. By the time you change a bug and test it, you’ve already finished your coffee.

Until one day, I came across an article about Rust compile time optimization that said one line of configuration could dramatically improve compile speed. I tried it with a skeptical attitude, and the compile time dropped from 22 minutes to 38 seconds.

No joke, just one line of configuration—that’s the power of Rust compile optimization.

Unveiling the Real Culprit Behind Slow Rust Compilation

Many developers think Rust compilation is slow because of the strict borrow checker or extensive generic expansion. These do have an impact, but the biggest bottleneck is actually in the final step—the linker.

What does the linker do? Simply put, the compiler translates your Rust code into scattered machine code fragments, and the linker’s job is to piece these fragments together into the final executable file. This linking process is a significant part of Rust compile time.

The problem is that Rust’s default linker is like an old-fashioned human-powered tricycle delivery person. It gets the job done, but it’s slow—one trip after another, incredibly inefficient, directly dragging down the entire Rust compile time.

Modern linkers like mold and lld, on the other hand, are like using electric tricycles or even small delivery trucks—zooming through, delivering the same items in just a few trips. This is why switching linkers can significantly reduce Rust compile time.

Linker Comparison Traditional linkers vs Modern linkers - The efficiency difference is staggering

Three Steps to Rust Compile Optimization: Configuration Guide

Here’s a detailed guide on how to optimize Rust compile time by switching linkers. The operation is very simple and only takes a few minutes.

Let’s cut to the chase.

Option 1: Use mold (First Choice for Linux, Fastest)

mold is currently the fastest linker, bar none. First, install it:

# Ubuntu/Debian
sudo apt install mold

# Arch Linux
sudo pacman -S mold

# macOS use sold (macOS version of mold)
brew install sold

Then create a .cargo/config.toml file in your project root and add these lines:

[target.x86_64-unknown-linux-gnu]
linker = "/usr/bin/clang"
rustflags = ["-C", "link-arg=--ld-path=/usr/bin/mold"]

That’s it. Run cargo build again, and you’ll discover a new world.

Cargo Build Compilation speed with mold - Flying fast

Option 2: Use lld (Cross-Platform Universal)

If you’re on Windows or too lazy to install mold, lld is also a good choice. It’s the LLVM project’s linker. While not as fast as mold, it’s much faster than the default.

[build]
rustflags = ["-C", "link-arg=-fuse-ld=lld"]

Just one line, simple and effective.

Option 3: Wait for Rust 1.90 (After September 2025)

The good news is that the Rust official team has recognized this problem. Starting from version 1.90, Linux will use rust-lld by default, so you don’t need manual configuration. But since it’s December 2025 now, if you’ve upgraded to 1.90 or higher, this problem might be automatically solved.

However, mold is still faster than lld. For those pursuing extreme performance, manual configuration is still recommended.

Rust Linker Configuration: Common Problems and Solutions

While switching linkers is simple, you might encounter some issues in actual operation. Here are common pitfalls and solutions.

Although the configuration is simple, there are a few traps to watch out for:

Trap 1: Linker Not Found

error: linker `mold` not found

This means mold isn’t installed or the path is incorrect. Use which mold to confirm the path and then change it to the correct one.

Trap 2: macOS Users Shouldn’t Use mold

On macOS, you should use sold, not mold. Although made by the same team, the macOS version is released separately with a different name.

# macOS configuration
[target.aarch64-apple-darwin]
rustflags = ["-C", "link-arg=-fuse-ld=/opt/homebrew/bin/sold"]

[target.x86_64-apple-darwin]
rustflags = ["-C", "link-arg=-fuse-ld=/usr/local/bin/sold"]

Trap 3: Remember to Configure CI Environment Too

If you configure it locally but not in CI, every CI run will still be slow. Remember to install the corresponding linker in your CI scripts or commit the config.toml to your repository.

Trap 4: wild Linker is Faster but Less Mature

If you like trying new things, you can try the wild linker, which is said to be even faster than mold. But it’s not mature enough yet—use with caution in production environments.

Rust Compile Optimization Results: Real Data Comparison

Let’s look at the actual performance data from real project cases.

Here are some real data points:

  • My own project: 22 minutes → 38 seconds
  • Someone online with 500k lines of code: 148 seconds → 23 seconds
  • Incremental builds: from 10 seconds down to 1-2 seconds

Compile Time Comparison Before and after optimization comparison - Data from actual projects

This isn’t just a small optimization—it’s a qualitative change.

Link time accounts for a high proportion in large projects, sometimes even more than half of the total compile time. This is why Rust compile time optimization is so important—switching to a faster linker is equivalent to compressing this half to one-tenth of its original time.

For developers pursuing extreme Rust compile time optimization, besides switching linkers, you can also consider using -C compiler flags for further optimization. But switching linkers is undoubtedly the highest cost-performance optimization solution.

Summary: Rust Compile Optimization Key Points

With the optimizations above, Rust compile time can be significantly improved. Remember these key points:

In three sentences:

  1. The biggest slowdown in Rust compilation is linking, not those fancy reasons you might think of
  2. Switch to mold or lld, one line of configuration, immediate results
  3. Rust 1.90+ uses lld by default, but mold is faster—for extreme performance, manual configuration is still needed

Next steps:

  • Create .cargo/config.toml in your project root
  • Copy the configuration above
  • Run cargo build once to feel the difference
  • Use the saved time to write more code (or slack off, I don’t care)

Efficiency Boost Time saved can be used for more meaningful things

Found this article helpful?

If this article saved you compilation waiting time, consider:

  1. Like it: Let more Rust developers suffering from compilation see this
  2. Share it: Your colleagues might also be staring at cargo build in a daze
  3. Follow Mengshou Programming: More practical Rust tips coming soon
  4. Comment: How long does your project take to compile? What results did you get after switching linkers?

Less time waiting for compilation, more time writing code. See you in the next article.