Faster compilation tricks

[u/TheAnalist_]

I’m developing epicenter using only features Cargo already provides to cut compile times and disk usage. The main one is a shared build-dir plus a store of already-compiled dependencies, so rustc doesn’t rebuild the same deps for every new project. On top of that I switched the linker to rust-lld and enabled incremental compilation for all profiles.

These three together already cut build times and disk usage significantly, but my goal is to push both as low as possible, so I’m willing to accept trade-offs (e.g. less debuginfo, slightly slower runtime in dev builds) as long as the defaults stay safe for most users. Is there anything else I’m missing? I’m thinking of things like split-debuginfo, reduced debug levels, per-package opt-level overrides for dependencies, or other Cargo/rustc settings that are not enabled by default but would pay off in this setup.

[u/dgkimpton]

Are you talking release mode or debug mode? In Debug I'm pretty sure most (if not all) optimisations are already off. Splitting debug symbols is just extra work.

Your best wins will splitting your project into smaller crates, more RAM, faster SSD, faster CPU, possibly a faster linker (wild?).

I'm not sure, but I suspect cargo build --frozen will yield marginal gains due to not checking for newer versions online.

[u/TheAnalist_ → u/dgkimpton]

I’d like to keep both modes, including all debugging functionality, and only optimize compilation times and disk usage. Epicenter will handle this for all projects on the machine, so I’m not looking for other solutions, such as splitting the code into smaller crates or adding more RAM. Adding compatibility for wild is a good idea

[u/dgkimpton → u/TheAnalist_]

I have no idea what epicenter is, but most compile time adjustments are per-project wins. Like, some projects really need LTO and symbol stripping to make reasonable sized binaries, others absolutely need debug symbols built in for reasonable error reporting. Tuning the features each project brings in (instead of just Default) makes a major difference. I don't think there's a one-size fits-all solution here.

[u/eikenberry]

Is there a resource online that gives instructions on how to do these optimizations to reduce compile times for someone new to the language?

[u/TheAnalist_ → u/eikenberry]

mostly the rust documentation, https://doc.rust-lang.org/stable/cargo/guide/build-performance.html

but I find it works best to test things out

[u/epage → u/TheAnalist_]

Our guide is fairly conservative (e.g. no share. build-dir).

For more, see https://corrode.dev/blog/tips-for-faster-rust-compile-times/

[u/rotundjose8]

split-debuginfo is a big one for disk usage, especially if you're building with debuginfo still on. offloading the dwarf to a separate file means the linker doesn't have to juggle it all in memory and your main binary stays lean.

for compile time, cranking the codegen units up in the dev profile can trade a bit of runtime perf for faster builds. also check if you can bump the lto setting down to "off" for dev if it's not already.

[u/BusinessBandicoot]

For debug use line tables only, thin lto, and wild. You can create a separate profile for actually attaching a debugger

[u/Upstairs-Project2756]

try setting debug to line-tables-only and opt-level 1 or 2 for dependencies. This drops compile time significantly without needing incremental builds or lld since the heavy lifting happens on dep code that changes rarely

[u/arjuna93]

The best trick is to use a different language

[u/rodrigocfd → u/arjuna93]

People will downvote you, but you have a point.

For a project, the choice of a programming language involves pros and cons, and one must consider all them. Rust will give you top notch correctness/performance, at the expense of long compilation times.

At the other side of the spectrum, we have languages like Go, which was specifically designed for fast compile times, at the expense of less correctness/performance. If compilation time is so important to OP, maybe a proof-of-concept should be considered.

Programming languages are just tools.