Why is the Rust Compiler So SLOW?

Rust compiler slowness in this case traces less to “lifetimes” and more to release-time optimization work—especially LLVM’s LTO and inlining—magnified by a dependency-heavy, async-heavy codebase. The practical pain shows up when containerizing a Rust web server: a naïve Dockerfile rebuilds the entire dependency graph every change, turning iteration into a multi-minute cycle.

The workflow starts with a common deployment pattern: compile a single static Rust binary, copy it into a Linux container, and restart. That approach works, but it’s slow under Docker because any code change invalidates the build context, forcing a full rebuild. In the author’s measurements, a clean release build took about four minutes, with roughly ten seconds of network time and the rest spent compiling and optimizing.

To fix the iteration loop, the discussion pivots to Docker build caching for Rust: using cargo chef to pre-build dependencies as a separate Docker layer. cargo chef generates a “recipe” for the workspace, caches dependency compilation, and ensures code edits only trigger recompilation of the application crate rather than hundreds of dependencies.

Once caching makes rebuilds tolerable, the next question becomes: why does the final release binary still take so long? Profiling with cargo timings and Rust’s self-profiling (via rusty with rustc’s self-profile flags) points to the final crate’s optimization pipeline. The biggest chunk is LLVM codegen and, within that, LTO-related optimization. Flame graphs and “icicle/stelactite” style views don’t reveal much visually, but LTO and LLVM module optimization dominate the wall time.

A deeper dive into LLVM pass timing shows that optimization passes like inlining and opt-function work are the heavy hitters. The analysis then turns up a surprising culprit: expensive compilation is tied to closures generated by async functions. Rust’s async lowering produces state machines that are represented internally with nested closures; when the profiler symbols are improved (switching mangling to v0ero), the trace becomes readable enough to identify which async-related closures and generic instantiations consume the most optimization time.

Armed with that, the author experiments with restructuring async code—splitting or refactoring large async blocks, changing how futures are pinned/boxed, and adjusting inlining behavior. One targeted change to a photo-processing async path drops an individual function’s optimization time dramatically (from multi-second to about ~2 seconds), though rerunning the full build shows only modest overall gains at first.

The broader optimization strategy becomes a mix of compiler knobs and build architecture: reducing inlining thresholds, lowering optimization for the final binary, and—most dramatically—changing dependency and build environment choices. Community follow-ups add further levers: enabling shared generics (with trade-offs), switching Docker base images away from Alpine (allocator and toolchain differences can swing compile times), and tuning LTO/debug settings.

The takeaway is not a single magic flag. It’s a chain: container rebuild strategy, then LLVM’s LTO/inlining costs, then Rust’s async-generated closure complexity and generic instantiation. The result is a roadmap for making Rust builds faster without abandoning Rust’s safety model—while also highlighting that the “cost” of deep optimization can dwarf dependency compilation in real projects.