Benchmarks

All numbers are cold builds (after cargo clean) on a 48-core Linux server with nightly Rust.

Virtual slicer — rust-perf standard suite (not yet re-verified)

These single-crate numbers were measured without -Z threads=8 or the wild linker. They have not been re-verified with the current fair-RUSTFLAGS protocol and may overstate speedups (same apples-to-oranges issue as the retracted workspace numbers above).

serde is already minimal — almost all of its code is reachable via derive macros. The slicer correctly identifies this.

Virtual slicer — real binary projects

All measurements use identical RUSTFLAGS for both baseline and vslice-cc (-Z threads=8 -C linker=clang -C link-arg=--ld-path=wild). 48-core machine, Apr 2026, 2–3 runs per mode.

Retracted claims: nushell was reported at 5.1× — apples-to-oranges RUSTFLAGS mismatch; re-measured speedup is 1.26×. cargo-slicer (self) was claimed at 1.74× but re-verified at 1.00× (only 1 driver crate, 0 stubs).

Docker benchmarks (docker run cargo-slicer bench)

Fair comparison inside Docker: same nightly toolchain, cargo fetch before timing (excludes download time), cargo clean between baseline and slicer. Slicer timing includes cargo-slicer pre-analyze overhead.

Docker speedups are higher than bare-metal for large projects (zed 2.11× vs 1.43×) because fewer cores amplify the benefit of eliminating codegen work — less parallelism means each eliminated function saves more wall time.

# Run the benchmark yourself
docker build -t cargo-slicer .
docker run --rm -v /path/to/project:/workspace/project cargo-slicer bench

Warm-cache daemon — verified (Apr 2026)

Both baseline and warmed use nightly + -Z threads=8. Interleaved rounds, dispatch pre-warmed, rm -rf target/ before each run.

An earlier version of this table claimed 8.5× for image (40.7 s → 4.8 s) and 1.7× for syn (6.7 s → 4.0 s). Those baselines were measured without -Z threads=8 and the wild linker, while the warmed runs had them — the same apples-to-oranges error as the nushell 5.1×. cargo 0.87.1 (claimed 2.3×) is a regression with fair RUSTFLAGS: baseline 15 s vs warmed 64 s — dispatch overhead serializes what -Z threads=8 parallelizes across 48 cores.

A warm cache populated by one project is reused across all projects on the same machine.

Upstream -Z dead-fn-elimination patch

These numbers come from the in-tree rustc patch (src/upstream_patch/), which implements the same algorithm natively in the compiler.

Patched stage1 oracle (rust-1.90.0 stable, 2026-04-26)

The in-tree patch was rebuilt against rust-1.90.0 (commit 1159e78c) with [rust] debug-assertions = true, overflow-checks = true to runtime-check the V9 invariant reachable_set ⊆ post-BFS-set.

debug_assert holds — no ICE, binary correct under the seed-set invariant.

ASE 2026 corpus sweep — top 2,669 crates by downloads

Correctness validation on a representative slice of the ecosystem. Run via scripts/bench_ase_corpus.sh; library crates gated on build success, binary crates additionally smoke-tested with --version / --help.

V10/V11 reframing (2026-04-29): numbers split by crate kind. The in-tree -Z dead-fn-elimination flag is a no-op on libraries today (V1 early-return); the userspace cargo-slicer tool's RUSTC_WRAPPER pipeline does run on libraries. They are reported separately so the in-tree claim applies only to the binaries it actually runs on.

Binary subset (n=65) — relevant to in-tree -Z dead-fn-elimination:

Library subset (n=2,538) — userspace cargo-slicer only, NOT the -Z flag: 2,393 of 2,538 libraries built under both legs with zero slicer-only failures; userspace median 1.50×. This number measures cross-crate orchestration in the userspace tool, not the single-crate in-tree flag.

Full corpus catalog (all 2,669 crates with rank, version, downloads, build times, and slicer status): ASE 2026 Corpus · CSV.

Full point-by-point response to the @petrochenkov V1–V11 review and reproduction instructions live in vadim-response-results.md on the cargo-slicer repository.

C/C++ projects — clang-daemon PCH acceleration

build-accelerate.sh (included in the image) auto-detects C/C++ projects and injects a precompiled header via clang-daemon. The technique eliminates repeated header parsing across parallel compilation units.

Already benchmarked (48-core server, Clang 21, -j48):

Predicted speedup for top starred projects (based on file count × header density model):

Key insight: speedup scales with (files × header parse fraction). Projects with thousands of files each including the same heavyweight headers (Linux, Godot, TensorFlow, Chromium) get the most benefit. Single-file amalgamations (sqlite3) and projects with shallow headers (Redis, Git) get little to none.

To run against any of these projects:

# Clone and accelerate (auto-detects C/C++ via compile_commands.json or Makefile)
git clone https://github.com/torvalds/linux
build-accelerate.sh ./linux

# Or via Docker (mounts your checkout)
docker run --rm --cpus=48 \
  -v $(pwd)/linux:/workspace/project \
  ghcr.io/yijunyu/cargo-slicer:latest

For projects using SCons (Godot) or Bazel (TensorFlow), generate compile_commands.json first:

# Godot
scons compiledb
# TensorFlow (CMake path)
cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -B build && cp build/compile_commands.json .

Running benchmarks yourself

# Multi-crate CI benchmark (7 projects, baseline vs vslice-cc, 3 runs each)
./scripts/ci_bench_multicrate.sh

# Individual project
./scripts/bench_fresh_build.sh nushell baseline 3
./scripts/bench_fresh_build.sh nushell vslice-cc 3

# RL training KPI report
cargo-slicer rl-bench --project /tmp/your-project --runs 2

Results are stored in bench-results.db (SQLite).