Skip to content

Add alternative linker to the build performance guide #15991

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Add alternative linker to the build performance guide #15991

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d243960
Add alternative linker to the build performance guide
Kobzol Sep 20, 2025
f0a5f75
Clarify code generation vs build times benefits
Kobzol Sep 21, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 30 additions & 2 deletions src/doc/src/guide/build-performance.md
View file
Open in desktop
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This reminds maybe we should consider a cargo native lld option for build.linker: #11378.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That might be nice indeed, but the situation with linkers is a bit complicated. You can use the self-contained LLD, or an external LLD, on Linux you invoke LLD through cc and -fuse-ld=lld, while elsewhere through -Clinker, if the linker is not lld, but something else unsupported by the CC driver, it cannot be specified by name, but has to be passed through some hacks with an absolute path.. it's quite messy.

Original file line number Diff line number Diff line change
Expand Up @@ -38,7 +38,7 @@ This will:
- Provide an opt-in for when debugging via [`--profile debugging`](../reference/profiles.md#custom-profiles)

Trade-offs:
- ✅ Faster build times
- ✅ Faster code generation (`cargo build`)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

imo that is too jargony without the surrounding context. When I see code generation, I think of the type of thing build scripts usually do

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I create some basic terminology at the start of the page, where we'll say that compilation is split into three categories (frontend, backend, codegen), and then we'll say in each mechanism which of these categories it helps?

- ✅ Faster link times
- ✅ Smaller disk usage of the `target` directory
- ❌ Requires a full rebuild to have a high-quality debugger experience
Expand Down Expand Up @@ -83,9 +83,37 @@ rustflags = "-Zthreads=8"
This [`rustflags`][build.rustflags] will enable the [parallel frontend][parallel-frontend-blog] of the Rust compiler, and tell it to use `n` threads. The value of `n` should be chosen according to the number of cores available on your system, although there are diminishing returns. We recommend using at most `8` threads.

Trade-offs:
- ✅ Faster build times
- ✅ Faster build times (both `cargo check` and `cargo build`)
- ❌ **Requires using nightly Rust and an [unstable Rust feature][parallel-frontend-issue]**

[parallel-frontend-blog]: https://blog.rust-lang.org/2023/11/09/parallel-rustc/
[parallel-frontend-issue]: https://github.com/rust-lang/rust/issues/113349
[build.rustflags]: ../reference/config.md#buildrustflags

### Use an alternative linker
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there any further linker tracking issues we should link out to, like

  • lld for more Linux targets
  • improving mac or windows
  • switching to wild

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is rust-lang/rust#39915 as global tracking issue for "use LLD everywhere", rust-lang/rust#71515 is for Linux (that one can probably be closed now) and rust-lang/rust#71520 for Windows.


Most targets default to using the system linker, which might not be the most performant option. You can try an alternative linker to see if it improves build performance.

Recommendation:

- Install an alternative linker, for example [LLD](https://lld.llvm.org/), [mold](https://github.com/rui314/mold) or [wild](https://github.com/davidlattimore/wild)
- Configure the Rust compiler to use a different linker. The configuration depends on the used linker and operating system. For Linux and the LLD or mold linker, you can add to your `.cargo/config.toml`:

```toml
# LLD
[target.'cfg(target_os = "linux")']
rustflags = ["-C", "link-arg=-fuse-ld=lld"]

# mold, if you have GCC 12+
rustflags = ["-C", "link-arg=-fuse-ld=mold"]

# mold, otherwise
linker = "clang"
rustflags = ["-C", "link-arg=-fuse-ld=/path/to/mold"]
```

> Note that since Rust `1.90.0`, the `x86_64-unknown-linux-gnu` target already defaults to the LLD linker.
Comment on lines +95 to +115
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have a rough feel for how fast the default linker is for each platform?

One of my concerns with this is handling the nuance of

  1. Going from default Linux linker to lld
  2. Going from lld to mold/wild

The way this is written, it makes it sound like everything is the level of gain of (1) and leaves x86_64-unknown-linux-gnu as more of a footnote. If that isn't the case, people may not be getting the gains they expect from this

Are Mac and Windows on the same level of the default Linux linker or more like lld?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On Mac the default linker should be "fast enough", since they shipped a new implementation a few yeargs ago. On Windows I saw people mentioning that LLD helps, but not always, it's probably not such a big deal as on Linux.

The biggest jump is definitely on Linux when going from BFD to LLD. If BFD's time was 1.0, then LLD is usually something like 0.1, mold maybe 0.05 and wild 0.03 (with a very big grain of salt). So going from BFD from LLD is the most important thing, the rest starts running into diminishing returns very quickly, unless you link Chrome or something similarly gargantuan.


Trade-offs:
- ✅ Faster link times
- ❌ Might not support all use-cases, in particular if you depend on C or C++ dependencies
Loading