Rust 1.96.0 Release Notes: 0% Faster, But Upgrade Anyway

0% measurable speedup in my quick smoke benches, but the Cargo CVE fixes and the LLVM 21 bump still make 1.96.0 a “measure, then move” upgrade.

Performance impact first (what I’d expect to move)

I’ve watched compiler upgrades do nothing for 99% of a codebase, then shave 7% off a single hot loop because LLVM changed one vectorization decision. That’s why I don’t trust “maintenance release” as a performance label.

Benchmarks vary by workload. On your code, Rust 1.96.0 can change runtime, compile time, and binary size mostly through the LLVM 21 toolchain shift and target-specific codegen tweaks.

• Runtime (hot paths): Treat the LLVM 21 requirement as “codegen may change.” Expect anything from -2% to +2% on typical server workloads, and bigger swings on tight numeric kernels. YMMV.
• Compile time (large workspaces): Plan to measure full clean builds and incremental builds separately. A “no change” release can still shift front-end checks (const generics typing) and move incremental behavior.
• Binary size (embedded, wasm): The AVR ABI fix and wasm linker behavior can change what ends up in the final artifact, even when your Rust source stays the same.

I ignore commit counts. I trust medians, p95, and a diff I can reproduce on Monday.

What changed (the short list that matters in production)

This bit me once on a Friday deploy. Cargo pulled from a nonstandard registry, an edge case got weird, and suddenly “build tooling” turned into a security surface area.

• Cargo security: Rust 1.96.0 ships fixes for two Cargo CVEs (CVE-2026-5222, CVE-2026-5223). Verify scope in the official advisories, then treat this as the non-negotiable reason to move.
• Toolchain baseline: Rust 1.96.0 raises the minimum external LLVM requirement to LLVM 21. If you build rustc against system LLVM, budget time for that upgrade.
• Stabilized APIs: assert_matches! and debug_assert_matches! go stable. This won’t speed up your service, but it will shorten test code and make failures easier to read.
• Target and ABI changes: AVR c_double now matches C’s 32-bit double on AVR targets. That can break FFI layouts and change generated code in surprising ways.
• Compatibility tightening: Rust blocks some patterns that “worked by accident,” including stricter const generic typing and tighter rules around Pin unsize coercions. Expect compile errors, not slowdowns.

How to benchmark Rust 1.96.0 yourself (before and after)

Measure it. Seriously.

I do this in two passes: one for build performance, one for runtime, and I keep the raw numbers in the PR. If you cannot reproduce the results, you cannot argue about them.

1) Pin two toolchains

Pick your “before” toolchain (likely 1.95.x) and “after” (1.96.0). Use rustup overrides so your shell does not lie to you.

• Install both: rustup toolchain install 1.95.0 1.96.0
• Pin per repo: write rust-toolchain.toml twice (or use rustup override set 1.95.0, then repeat with 1.96.0)
• Verify: run rustc –version and paste it into your benchmark log

2) Compile-time benchmark (clean and incremental)

The thing nobody mentions is CI cache heat. A warm build can hide a 12% regression in clean builds, and that matters when you rotate builders or blow caches.

• Clean build time: run cargo clean, then time cargo build –release 5 times, report median and p95.
• Incremental build time: make a tiny edit (one file, one function), then time cargo build 10 times, report median.
• Noise control: keep CPU governor consistent, close Chrome, and do not benchmark on a laptop in “battery saver.” Yes, I’m that person.

3) Runtime benchmark (micro + macro)

Microbenchmarks catch codegen shifts. Macrobenchmarks catch everything else, allocator behavior, IO, cache misses, the messy stuff.

• Micro (Criterion): run cargo bench, compare medians, flag anything past 2% unless the variance looks ugly.
• Macro (real workload): replay a production-like request trace or run a fixed dataset job. Report throughput and p95 latency, not just “it felt fine.”
• Profiling follow-up: if you see a regression, capture a flamegraph on both toolchains before you start guessing.

Breaking changes and “gotchas” I would gate in CI

Some folks yolo patch releases on Friday. I don’t, but I get it.

• AVR c_double mapping: Audit every FFI boundary that uses c_double. Re-check struct layouts, and rerun your hardware-in-the-loop tests if you have them.
• External LLVM must be 21: If your distro image pins LLVM 20, your “upgrade Rust” task becomes “upgrade LLVM, then rebuild rustc.” That can add hours.
• Wasm undefined symbols: If you relied on the wasm linker allowing undefined symbols, expect builds to fail until you add an explicit linker arg in your config.
• Removed -Csoft-float: If you used it, switch to a softfloat target/ABI that matches what you actually run.
• Tighter type checks: Stricter const generic typing can break builds that leaned on inference. Fix it once, then enjoy fewer spooky errors later.

If you can’t benchmark your compiler upgrade in staging, you probably shouldn’t run Rust in production.

Upgrade recommendation (numbers-first)

The numbers say upgrade, but only after you run the three benchmarks above and you capture the medians in a PR comment. Security fixes in Cargo push this toward “soon,” and the rest looks like normal tightening and cleanup.

Anyway. There’s probably a better way to automate the whole before-after harness across every crate in a monorepo, but I haven’t found a setup I love yet.