2024年5月17日 · Rémy Rakic 代表 编译器性能工作组
TL;DR: 在 nightly 版本中，rustc 将默认在 x86_64-unknown-linux-gnu 平台上使用 rust-lld，以显著减少链接时间。
一些背景
链接时间通常是编译时间的一大部分。当 rustc 需要构建二进制文件或共享库时，通常会调用系统上安装的默认链接器来完成（这可以在命令行或代码编译的目标上更改）。
链接器完成了一项重要的工作，包括稳定性、向后兼容性等问题。因此，在最流行的操作系统上，它们通常是设计较早的程序，当时计算机只有一个核心。因此，它们在现代机器上通常较慢。例如，在 Linux 上以调试模式构建 ripgrep 13 时，大约一半的时间实际上是在链接器上花费的。
然而，有不同的链接器，通常建议使用这些较新和较快的链接器之一，如 LLVM 的 lld 或 Rui Ueyama 的 mold 来提高链接时间。
Rust 的一些 wasm 和 aarch64 目标已经默认使用 lld。使用 rustup 时，rustc 自带一个 lld 版本用于此目的。当 CI 构建 LLVM 以用于编译器时，它也会构建链接器并打包它。为了避免与用户机器上已安装的 lld 冲突，称它为 rust-lld。
由于链接时间的改进是显著的，因此在最流行的目标中使用它作为默认值是个好选择。这个话题已经讨论了很长时间，例如在问题#39915和#71515中，并且 rustc 已经提供了使用 rust-lld 的 nightly 标志。
到目前为止，我们相信我们已经在 CI、crater 和我们的基准测试基础设施上进行了所有的内部测试。我们现在希望扩展测试并收集真实世界的反馈和用例。因此，我们将在 nightly 版本中默认启用 rust-lld 作为 x86_64-unknown-linux-gnu 的链接器。
收益
虽然这也使编译器能够在未来使用更多的链接器功能，但最直接的好处是大大改进了链接时间。
以下是前面提到的 ripgrep 示例的详细信息：链接时间减少了7倍，最终编译时间减少了40%。
大多数二进制文件应该会在这里看到一些改进，但特别是在较大的二进制文件或涉及调试信息时，这些通常会在链接器中遇到瓶颈。
这是我们基准测试的完整结果链接。
如果测试顺利，我们可以将此更快的链接器默认用于 x86_64-unknown-linux-gnu 用户，然后再考虑其他目标。
可能的缺点
根据我们之前的测试，我们实际上不期望在实践中出现问题。在绝大多数情况下，它是一个直接的替代品，但 lld 并不是与 GNU ld 完全兼容。
在任何情况下，如果出现问题，可以禁用使用 rust-lld：使用 -Z linker-features=-lld 标志恢复使用系统的默认链接器。
某些依赖这些差异的 crate 可能需要额外的链接参数。例如，我们在 crater 运行中看到 <20 个 crate 因为关于封装符号的不同默认值而无法链接：这些可能需要 -Clink-arg=-Wl,-z,nostart-stop-gc 来匹配传统的 GNU ld 行为。
一些性能的巨大提升来自并行性，这在资源受限的环境中可能是不可取的。
总结
rustc 将在 x86_64-unknown-linux-gnu 的 nightly 版本上使用 rust-lld，以显著改进链接时间，从明天的 rustup nightly（nightly-2024-05-18）开始。如果遇到问题，请在 GitHub 上打开一个问题告知我们。
如果发生这种情况，您可以使用 -Z linker-features=-lld 标志恢复默认链接器。可以将其添加到常用的 RUSTFLAGS 环境变量，或项目的 .cargo/config.toml 配置文件中，如下所示：
ini
[target.x86_64-unknown-linux-gnu]
rustflags = ["-Zlinker-features=-lld"]