Compilation perf: linker replacement consideration?

[kwonoj]

This is not an official RFC or proposal, more of a casual thought.

Compilation / build performance of rust application does not come from a single offender but requires continuous exploration across various domains. I'm not trying to say replacing a linker would resolve all the costs for our build performance. However, given we're seeing some of slow build speed (on CI, mostly for release build) it maybe interesting to consider to use different linker.

This is a very small example on Windows between msvc. vs lld on i7-1165G7.

// msvc (default)
   Compiling swc_cli v0.3.1 (C:\github\swc\crates\swc_cli)
    Finished release [optimized] target(s) in 12m 33s

// rust-lld
[target.x86_64-pc-windows-msvc]
linker = "rust-lld.exe"

  Compiling swc_cli v0.3.1 (C:\github\swc\crates\swc_cli)
    Finished release [optimized] target(s) in 7m 45s 

msvc + windows is probably not a good example to guess all platform perfs as link perf on msvc would be lot slower than other platforms. However, I'd guess we'd get some of performance gain across stiil.

• What linker should be used?
  lld (and maybe mold for linux)?

• Pros
  (maybe) faster link perf

• Cons
  Setup requires additional steps to have llvm (or other linkers) installed.

[kdy1]

I think it's good idea, CI is too slow. (Seems like there was some regression recently)

[kwonoj]

One caveat is as wrote above it needs additional llvm installation - local dev have too do it too. Maybe not a super huge concern?

[kdy1]

I think it's fine, but we can use some shell scripts to enable it only on CI

[kwonoj]

Let's try to set as default and see how disruptive it'll be? I'd favor to have better link perf on local machines as well, and having same linker on local makes less chance to see surprise on ci machine's binary only.

If cargo supports toolchain setup / or fallback things would be easier.

Anyway, let me come up with PR to replace linker one by one.

[kdy1]

Oh, I agree that it can be surprising