Add alternative linker to the build performance guide

[Kobzol]

This one is tricky, because the configuration depends on the used linker and also the OS. Should we add configuration for all of Linux, Windows and Mac?

Also I didn't like starting with one with "Recommendation: ", as I think that it deserves at least a sentence of context. Actually I'd like to add this intro context before the "Recommendation: " part to all existing sections (let me know if you agree or not).

One thing I was also considering is whether we should describe the expected wins in a more detailed fashion. For example, to answer questions like: "does this help check builds?", "does this help incremental rebuilds or full builds, or both?". Regarding the linker, it won't help at all for check builds, but on the other hand it will have an even bigger effect for incremental rebuilds than for full builds, because linking is not incremental at the moment, so it typically takes a larger % out of the total build time in incremental builds.

r? @epage

[weihanglo]

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

[Kobzol]

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.

[epage]

This one is tricky, because the configuration depends on the used linker and also the OS. Should we add configuration for all of Linux, Windows and Mac?

This is also tricky because the possible gains are very platform specific.

Also I didn't like starting with one with "Recommendation: ", as I think that it deserves at least a sentence of context.

This has enough nuance that I don't think that style works well here

Actually I'd like to add this intro context before the "Recommendation: " part to all existing sections (let me know if you agree or not).

This depends.

One thing I was also considering is whether we should describe the expected wins in a more detailed fashion. For example, to answer questions like: "does this help check builds?", "does this help incremental rebuilds or full builds, or both?". Regarding the linker, it won't help at all for check builds, but on the other hand it will have an even bigger effect for incremental rebuilds than for full builds, because linking is not incremental at the moment, so it typically takes a larger % out of the total build time in incremental builds.

Can't the linker help check builds when proc macros and build scripts are present? Granted, less is being linked so maybe its unnoticable.

Discussing benefitted workflows seems reasonable.

[Kobzol]

Can't the linker help check builds when proc macros and build scripts are present? Granted, less is being linked so maybe its unnoticable.

It will help somewhat, but these crates are typically rather small, and only compiled "once", so it won't be noticeable for incremental rebuilds, while linking time for the main binary can be quite noticeable for rebuilds.

I split the benefits into "code generation" (build) and "build times" (check + build).

[epage]

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

[Kobzol]

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?

[epage]

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?

[Kobzol]

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.

[epage]

So we have two camps:

• Big change for non-x64 Linux
• Small change for all platforms

Can we capture that nuance somehow? In seeing a section like this, to me it sets the expectation that there will be big gains but for most users, the gains will be quite small. Thinking about the use of non-x64 Linux, I almost wonder if we should focus our wording on the small change and relegate non-x64 Linux to a footnote.

[Kobzol]

I tried to enumerate the expected wins for the three major OSes.

[epage]

I went ahead and took a crack at an alternative framing and would be interested in your thoughts: https://github.com/epage/cargo/blob/build-performance-linker/src/doc/src/guide/build-performance.md#use-an-alternative-linker

• Don't bother with ldd in the example, shifting more of the emphasis to mold, wild
• Demoting this item from a Recommendation to a Consider because of the expected gains and trade offs
• Simplified discussion of platforms, focusing on non-x86 Linux and everything else, including only linking to the "ldd everywhere" issue

[Kobzol]

I like the framing in general. That being said, I think that for Windows it can still be quite useful to use LLD (mold and wild don't support Windows at all, just Linux). So I'd at least include LLD in the list of example linkers.

[epage]

If you feel it's helpful enough, sure. I removed it because it's redundant for some platforms and you said it had mixed results on Windows, so it seemed hard to describe with limited benefit, making it seem not worth it.

[Kobzol]

Incorporated your text with slight edits, to make it seem less Linux is really the only case where a different linker might help.