| name | rust-build-optimization |
| description | Use when a Rust or Cargo build is slow and the user wants it diagnosed or sped up: profiling compile times with cargo --timings or -Zself-profile, finding whether the bottleneck is dependencies, codegen/LLVM, linking, or one oversized crate, and applying targeted fixes such as faster linkers (lld, mold, wild), incremental compilation, dev/release profile tuning, workspace splitting, Cranelift, the nightly parallel frontend, or CI caching with sccache. Also for reviewing .cargo/config.toml or Cargo.toml profile settings for build speed. Not for making the compiled program run faster (runtime optimization), general Rust coding or debugging questions, or non-Rust build systems. |
| version | 0.1.0 |
| category | development-workflows |
| tags | ["rust","cargo","compile-times","build-performance","linker","profiling"] |
| argument-hint | [project-path or symptom] |
| allowed-tools | Read, Write, Edit, Glob, Grep, Bash |
Rust Build Analysis and Optimization
Diagnose slow Rust builds by measuring first, then apply the smallest fix that
targets the actual bottleneck. The useful outcome is: a baseline number, a
named bottleneck backed by profiler output, applied configuration changes, and
a re-measured result — not a pile of speculative config.
Path note: <skill-dir> below means this skill's own directory. Substitute
the literal path announced when the skill loads; do not use $SKILL_DIR.
Hard Rules
- Never recommend a fix before at least one measurement supports it.
- Label every nightly-only or platform-specific option as such.
- Do not silently change settings that affect release runtime performance
(
codegen-units, lto, opt-level in [profile.release]); state the
tradeoff and get agreement.
- Re-measure after applying changes and report before/after numbers.
Step 1 — Frame the Complaint
Establish three facts before touching anything:
- Cold or warm? Full build after
cargo clean / dependency bump, or an
incremental rebuild after a one-line change? They have different
bottlenecks and different fixes.
- Which profile?
dev, release, or CI. Ask, or read the command the
user actually runs.
- Baseline. Time the exact complained-about scenario once, e.g.
cargo build --release after touch-ing a source file for warm builds.
Also check the trivial win first: if the user's inner loop is "edit → build →
read errors", cargo check (or bacon / cargo watch -x check) skips
codegen entirely and is often the single biggest quality-of-life fix.
Step 2 — Measure
Start with the built-in profiler:
cargo build --timings
Read it for: slowest units, the concurrency graph (long single-threaded tails
mean a serialization problem), and whether the final bin crate dominates.
Known blind spot: for the warm rebuild of a bin crate, --timings shows one
opaque block — codegen and link time are not broken out. When that block is
the mystery, go deeper with -Zself-profile and measureme
( / / ), , or linker timing.
Full tool guide: .
