With all the respect to the author and his wild experiments, that title does not match the linker-only focus of the content.
So not only the post ended up with two (IMHO) bad recommendations (disabling debug info, building non-relocatable binaries with musl). But it also didn’t mention other important factors like codegen-unitsand codegen-backend. Since you know, code generation is the other big contributor to the cycle time (the primary contributor even, in many cases). There is also other relevant options like lto and opt-level.
Let’s assume that opt-level shouldn’t be changed from defaults for no good reason.
With codegen-units, it’s not the default that is the problem, but the fact that some projects set it to 1 (for performance optimization reasons), but without adding a separate profile for development release builds (let’s call it release-dev).
Same goes for lto, where you can have it set to "full" in your optimized profile, and completely "off" in release-dev.
And finally, with codegen-backend, you can enjoy what is probably the biggest speed up in the cycle by using cranelift in your release-dev profile.
And of course you are not limited to just two release profiles. I usually use 3-4 myself. Profile inheritance makes this easy.
And finally, you can set/not set some of those selectively for your dependencies. For example, not using cranelift for dependencies can render the runtime performance delta negligible in some projects.
Using the parallel rustc front-end might become an interesting option too, but it’s not ready yet.
With all the respect to the author and his
wildexperiments, that title does not match the linker-only focus of the content.So not only the post ended up with two (IMHO) bad recommendations (disabling debug info, building non-relocatable binaries with musl). But it also didn’t mention other important factors like
codegen-unitsandcodegen-backend. Since you know, code generation is the other big contributor to the cycle time (the primary contributor even, in many cases). There is also other relevant options likeltoandopt-level.Let’s assume that
opt-levelshouldn’t be changed from defaults for no good reason.With
codegen-units, it’s not the default that is the problem, but the fact that some projects set it to 1 (for performance optimization reasons), but without adding a separate profile for development release builds (let’s call itrelease-dev).Same goes for
lto, where you can have it set to"full"in your optimized profile, and completely"off"inrelease-dev.And finally, with
codegen-backend, you can enjoy what is probably the biggest speed up in the cycle by usingcraneliftin yourrelease-devprofile.And of course you are not limited to just two release profiles. I usually use 3-4 myself. Profile inheritance makes this easy.
And finally, you can set/not set some of those selectively for your dependencies. For example, not using
craneliftfor dependencies can render the runtime performance delta negligible in some projects.Using the parallel rustc front-end might become an interesting option too, but it’s not ready yet.