Three prevalent themes in the discussion
| Theme | Summary | Representative quote |
|---|---|---|
| 1. Why Rust compiles slowly | The consensus points to Rust’s rich static guarantees—especially monomorphization of generics, complex trait resolution, and the borrow checker—as the main sources of extra IR work that LLVM (or another backend) must process. | “Rust just generates a ton of IR for LLVM to chew on (because of monomorphization), then LLVM takes a while to process all of it.” – kibwen “rust compilation is slower because the compiler is doing way more things compared to C (monomorphization, complex trait resolution + type inference, borrow checker..)” – thevinter* |
| 2. How compile times can be improved | Contributors highlight algorithmic changes, incremental/caching techniques, alternative backends, and crate‑level strategies (splitting crates, earlier metadata emission, macro idempotence) as effective ways to cut wall‑time. | “Going from ~1.5M to ~90K apply_effects_in_block calls by changing the CFG traversal is a reminder that the biggest compiler optimizations often come from changing the algorithm, not optimizing the hot loop itself.” – Citrusoff “If they [macros] are [treated as idempotent] then incr comp can be faster by not evaluating them unnecessarily.” – estebank “Emit the meta data about function types earlier for downstream slots to use… Something like 40% wall time speed up” – knuckleheads |
| 3. Trade‑offs and priorities | Many note that slower compile times are the price for Rust’s safety and performance guarantees; some argue compile time isn’t the only productivity factor, while others still want faster builds for rapid iteration. | “If you want something like Rust that offers guarantees and checks … it adds up.” – jerf “Rust can't be Go in terms of compile times if it wants to offer the guarantees and options it does.” – ModernMech “Compile times are rarely the bottleneck for me, but that doesn't mean I won't welcome any improvements on that front.” – estebank |