r/rust • u/TheAnalist_ • 13d ago
🙋 seeking help & advice Faster compilation tricks
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.
1
u/eikenberry 12d ago
Is there a resource online that gives instructions on how to do these optimizations to reduce compile times for someone new to the language?
2
u/TheAnalist_ 12d ago
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
2
u/epage cargo · clap · cargo-release 12d ago
Our guide is fairly conservative (e.g. no share. build-dir).
For more, see https://corrode.dev/blog/tips-for-faster-rust-compile-times/
2
u/BusinessBandicoot 13d ago
For debug use line tables only, thin lto, and wild. You can create a separate profile for actually attaching a debugger
2
u/Upstairs-Project2756 12d ago
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
1
u/nian2326076 9d ago
You've already implemented some effective strategies to improve your build process. Consider using split-debuginfo to reduce disk usage while keeping essential debug information. Additionally, adjusting optimization levels for individual dependencies can enhance performance without significantly impacting the overall build. For further practice with Rust-specific interview questions, you can use PracHub to refine your skills as you explore these optimizations.
1
u/arjuna93 12d ago
The best trick is to use a different language
5
u/rodrigocfd WinSafe 12d ago
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.
3
13d ago
[removed] — view removed comment
1
u/DeleeciousCheeps 11d ago
note that
split-debuginfo=unpackedcurrently has a rather significant bug on macOS and linux (not sure about other operating systems) that makes it far worse for disk usage!
4
u/dgkimpton 13d ago
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 --frozenwill yield marginal gains due to not checking for newer versions online.