Skip to content
Free public beta until December 4, 2026: every course is open, no card needed. After that, the first chapter of each course stays free and full access is a one-time $39 ($19 for up to 100 founding members chosen for helpful feedback). Your progress is kept. How the beta works

Recipe

Shrink a release binary

Use when: a release executable is bigger than you want to download or ship, and you're choosing profile settings

Goal: a [profile.release] where every setting was measured and kept only because it paid for its cost

Taught in Release builds and binary size

Quick recipe

  1. Measure the baseline
  2. Add one setting, rebuild clean, measure
  3. Try LTO and one codegen unit together
  4. Decide about panic = "abort" separately
  5. Check speed before you keep it
  1. 1

    Build with cargo build --release and no size settings, and write down the size of the file in target/release/.

    Why: every later number means something only next to the one you started from.

  2. 2

    Add a single setting (strip = true first), run cargo clean and cargo build --release, and record the size and the build time.

    Example

    On dockstat, strip = true took 925,536 bytes to 730,592 with no change in build time.

    Why: settings interact, and a partial rebuild can hide or blame the wrong change.

  3. 3

    Add lto = true and codegen-units = 1, then try opt-level = "s" or "z" on top.

    Why: these let the optimizer see the whole program, and the size-first opt-levels often only pay off once it can.

  4. 4

    Keep it only if nothing in the program depends on unwinding: no thread that is allowed to panic while others carry on, no catch_unwind, no cleanup in Drop that must happen on a panic.

    Why: it's the one size setting that changes what the program does, not only how big it is.

  5. 5

    Time the release program on real input with and without the final settings.

    Why: a smaller file that runs slower may not be the trade you wanted.