For certain workloads linking with the gold linker on Linux can speed up compilation quite a bit. Servo, for example, goes to lengths to link with gold (it can be done with the rustc flag -C link-args=-fuse-ld=gold) because it improves link time dramatically for their large project.
I think we should probably be using gold by default when possible to get the performance improvements. It’s not a simple matter though since gold is not completely compatible with ld. Still, this incompatibility might be a good reason to move to gold now, to establish the precedent that linking on Linux uses gold, maybe prevent those gold-broken linkage scenarios from ever occurring.
Here’s a simple patch that just reads an environment variable RUSTC_LINK_WITH_GOLD. This is probably not the right way to do it though. We might alternately detect whether the gold bin is available and just use it unless some flag indicates not to.
That’s the sum of my thoughts for now. Want to get this subject moving since it’s such an easy compile time win for some cases.
If crater ran cargo test --no-run then it’d be doing quite a bit of linking (right now rlib generation doesn’t run a linker), and perhaps that’d be a good testing bed for trying out gold by default?
I would also be fine doing something like recognizing -C linker=gold or -C gold-linker at the compiler level in a more first class fashion for detecting gold.
I would rather have gold be a hard dependency on Linux, at least on x86_64 and x86–as in, the only linker supported, a mandatory dependency of any Rust .deb/.rpm/etc. package. This way, in addition to things being faster, link-time optimization would work uniformly.
As far as Windows goes, I think LLD is the solution. I’m looking forward to having LLD in the -msvc edition as soon as it is ready.