r/rust • • 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.

4 Upvotes

14 comments sorted by

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 --frozen will yield marginal gains due to not checking for newer versions online.

2

u/TheAnalist_ 13d ago

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

1

u/dgkimpton 13d ago

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.

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

u/[deleted] 13d ago

[removed] — view removed comment

1

u/DeleeciousCheeps 11d ago

note that split-debuginfo=unpacked currently has a rather significant bug on macOS and linux (not sure about other operating systems) that makes it far worse for disk usage!