Rust Build Times

Purpose

Guide agents through diagnosing and improving Rust compilation speed: cargo-timings for build profiling, sccache for caching, the Cranelift codegen backend for faster dev builds, workspace crate splitting, LTO configuration trade-offs, and fast linkers (mold/lld).

Triggers

• "My Rust project takes too long to compile"

• "How do I profile which crates are slow to build?"

• "How do I set up sccache for Rust?"

• "What is the Cranelift backend and how does it help?"

• "Should I use thin LTO or fat LTO?"

• "How do I use the mold linker with Rust?"

Workflow

1. Diagnose with cargo-timings

Build with timing report

cargo build --timings

Opens build/cargo-timings/cargo-timing.html

Shows: crate compilation timeline, parallelism, bottlenecks

For release builds

cargo build --release --timings

Key things to look for in the timing report:

- Long sequential chains (no parallelism)

- Individual crates taking > 10s (candidates for optimization)

- Proc-macro crates blocking everything downstream

cargo-llvm-lines — count LLVM IR lines per function (monomorphization)

cargo install cargo-llvm-lines cargo llvm-lines --release | head -20

Shows functions generating the most LLVM IR (template explosion)

2. sccache — compilation caching for Rust

Install

cargo install sccache

or: brew install sccache

Configure for Rust builds

export RUSTC_WRAPPER=sccache

Add to .cargo/config.toml (project or global)

~/.cargo/config.toml

[build] rustc-wrapper = "sccache"

Check cache stats

sccache --show-stats

S3 backend for CI teams

export SCCACHE_BUCKET=my-rust-cache export SCCACHE_REGION=us-east-1 export AWS_ACCESS_KEY_ID=xxx export AWS_SECRET_ACCESS_KEY=yyy sccache --start-server

GitHub Actions with sccache

- uses: mozilla-actions/sccache-action@v0.0.4

3. Cranelift codegen backend

Cranelift is a fast codegen backend (vs LLVM) — produces slower code but compiles much faster. Ideal for development builds:

Install nightly (Cranelift requires nightly for now)

rustup toolchain install nightly rustup component add rustc-codegen-cranelift-preview --toolchain nightly

Use Cranelift for dev builds only

.cargo/config.toml

[unstable] codegen-backend = true

[profile.dev] codegen-backend = "cranelift"

Use per-build

CARGO_PROFILE_DEV_CODEGEN_BACKEND=cranelift
RUSTFLAGS="-Zunstable-options"
cargo +nightly build

Cranelift vs LLVM trade-off:

• Dev builds: 20–40% faster compilation with Cranelift

• Runtime performance: LLVM-compiled code is faster (Cranelift skips many optimizations)

• Release builds: always use LLVM

4. Workspace splitting for parallelism

A single large crate compiles sequentially. Split into smaller crates to enable Cargo parallelism:

Before: one giant crate

[package] name = "monolith" # everything in one crate = sequential compile

After: workspace with parallel crates

[workspace] members = [ "core", # compiled in parallel "networking", # no deps on ui → parallel with ui "ui", # no deps on networking → parallel "server", # depends on core + networking "cli", # depends on core + ui ]

Visualize dependency graph

cargo tree | head -30 cargo tree --graph | dot -Tsvg > deps.svg # visual graph

Check how many crates compile in parallel

cargo build -j$(nproc) --timings # maximize parallelism

Rules for effective workspace splitting:

• Break circular dependencies first

• Separate proc-macros into their own crate (they block everything)

• Keep frequently-changed code isolated (less invalidation)

5. LTO configuration

LTO improves runtime performance but increases link time:

Cargo.toml profile configuration

[profile.release] lto = "thin" # thin LTO: good performance, much faster than "fat" codegen-units = 1 # needed for best optimization (but disables parallelism)

[profile.release-fast] inherits = "release" lto = "fat" # full LTO: maximum performance, very slow link

[profile.dev] lto = "off" # never use LTO in dev (compilation speed) codegen-units = 16 # maximize parallel codegen in dev

LTO comparison:

Setting Link time Runtime perf Use when

lto = false

Fast Baseline Dev builds

lto = "thin"

Moderate +5–15% Most release builds

lto = "fat"

Slow +15–30% Maximum performance

codegen-units = 1

Slowest Best With LTO for release

6. Fast linkers

The linker is often the bottleneck for large Rust projects:

mold — fastest general-purpose linker (Linux)

sudo apt-get install mold

.cargo/config.toml

[target.x86_64-unknown-linux-gnu] linker = "clang" rustflags = ["-C", "link-arg=-fuse-ld=mold"]

Or use cargo-zigbuild (uses zig cc as linker)

cargo install cargo-zigbuild cargo zigbuild --release

lld — LLVM's linker (faster than GNU ld, available everywhere)

.cargo/config.toml

[target.x86_64-unknown-linux-gnu] rustflags = ["-C", "link-arg=-fuse-ld=lld"]

On macOS: zld or the default lld

[target.x86_64-apple-darwin] rustflags = ["-C", "link-arg=-fuse-ld=/usr/local/bin/zld"]

Linker speed comparison (large project, typical):

• GNU ld: baseline

• lld: ~2× faster

• mold: ~5–10× faster

• gold: ~1.5× faster

7. Other quick wins

Reduce debug info level (faster but less debuggable)

Cargo.toml

[profile.dev] debug = 1 # 0=off, 1=line tables, 2=full (default)

debug=1 saves 20-40% on debug build time

Split debug info (reduces linker input)

[profile.dev] split-debuginfo = "unpacked" # macOS: equivalent of gsplit-dwarf

Disable incremental compilation (sometimes faster for full rebuilds)

CARGO_INCREMENTAL=0 cargo build

Reduce proc-macro compile time (pin heavy proc-macro deps)

Heavy proc-macros: serde, tokio, axum — keep versions stable

Related skills

• Use skills/rust/cargo-workflows for Cargo workspace and profile configuration

• Use skills/build-systems/build-acceleration for C/C++ equivalent build acceleration

• Use skills/debuggers/dwarf-debug-format for debug info size/split-dwarf tradeoffs

• Use skills/binaries/linkers-lto for LTO internals