ASE 2026 Corpus

The ASE 2026 corpus is the empirical evaluation set for cargo-slicer's correctness and speedup claims. It is the top 2,669 crates by all-time downloads on crates.io, fetched 2026-04-26.

This page is the canonical reference for the corpus. Other documents and README sections that mention "the ASE 2026 corpus sweep" link here.

Headline numbers

Note (2026-04-29 reframing). Per follow-up review V10/V11 from @petrochenkov, speedup numbers are split by crate kind. The in-tree -Z dead-fn-elimination flag is a no-op on libraries today (early-return when entry_fn().is_none()), so library numbers cannot be folded into a single headline alongside binary numbers. The userspace cargo-slicer tool's RUSTC_WRAPPER pipeline does run on libraries, and its numbers are reported separately below. See docs/vadim-response-results.md for the full V10/V11 discussion.

Corpus shape (single sweep, both legs)

Across the full corpus the slicer leg never failed when the baseline succeeded — this correctness statement holds for both kinds.

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

The library median is not a claim about -Z dead-fn-elimination. It is a measurement of cross-crate orchestration in the userspace tool, which is where (per V11) the algorithm actually earns its keep — single-crate elimination overlaps heavily with -Wunused + monomorphization + LLVM DCE.

Speedup distribution

The wall-time regression tail (speedup < 1.0×, 26.9% of crates) is concentrated on tiny crates where the slicer's per-invocation overhead dominates a sub-1-second baseline build. None of these 660 crates are correctness regressions — every one of them produced a correct binary; they just took longer to build than the baseline. For full reproducibility, all of them are kept in the corpus and in the published CSV.

Methodology

# 1. Fetch top 2,669 crates by downloads
ase2026d/crates-corpus/fetch-crates.sh

# 2. Run baseline + slicer back-to-back on each tarball, 8-way parallel
for f in fetch/*.crate; do
    while [ "$(jobs -r -p | wc -l)" -ge 8 ]; do wait -n; done
    NAME=...; VERSION=...
    ./scripts/bench_ase_corpus.sh "$NAME" "$VERSION" &
done
wait

# 3. Aggregate
python3 scripts/aggregate_ase_results.py > results/aggregate_full.json

For each crate the harness:

1. Extracts the tarball.
2. Runs cargo +nightly build --release --offline (baseline), retrying online once on failure to fetch transitive deps.
3. Runs cargo +nightly build --release again under RUSTC_WRAPPER=cargo_slicer_dispatch with CARGO_SLICER_VIRTUAL=1 CARGO_SLICER_CODEGEN_FILTER=1.
4. For binary crates: smoke-tests the produced binary with --version then --help (both legs must succeed for "correctness_ok").
5. For library crates: build success is the correctness signal — cargo test is intentionally skipped on the slicer leg because the userspace slicer over-stubs #[test] functions (V7 issue, orthogonal to dead-fn-elimination's binary-output property).
6. Records (baseline_secs, slicer_secs, speedup, correctness_ok) to results/<name>-<version>.bench.json.

Top 25 by speedup

These are the crates with the largest wall-time speedup. The pattern: tiny library crates whose baseline is dominated by codegen of a few large unreachable functions that the slicer eliminates entirely.

Top 25 by downloads

These are the most-depended-upon crates in the corpus. Speedups are more modest because their baselines are already small and their workspaces already have most code reachable through derive macros and re-exports.

bitflags, base64, quote, itertools, thiserror: ~1.0× or worse — these crates are tiny (sub-second baseline) and the slicer's per-invocation overhead dominates. They are not correctness regressions.

Full per-crate data

The complete table — all 2,669 crates with rank, version, downloads, build times, and slicer status — lives in a single CSV in the source tree:

docs/ase2026-corpus.csv

Schema:

rank,name,version,downloads,kind,baseline_build_secs,slicer_build_secs,speedup,status
1,syn,2.0.117,1595761057,lib,5.42,4.33,1.252,both_built
2,hashbrown,0.17.0,1469613376,lib,1.92,1.49,1.295,both_built
...

status values:

• both_built — baseline + slicer both succeeded; speedup is meaningful.
• baseline_failed — the baseline cargo build itself failed (missing feature combos, target dependencies, etc.); the slicer leg is not attempted.
• slicer_regression — baseline succeeded, slicer failed. The corpus contains zero entries with this status — that is the headline correctness claim.
• error_tarball_missing — fetch failure during fetch-crates.sh.
• not_run — corpus entry without a matching result file (typically semver-with-build-metadata that the harness split mis-parsed).

Where this corpus is referenced

• Root README
• Benchmarks → ASE 2026 corpus sweep
• Virtual Slicer → Review status
• docs/upstream-rfc.md — MCP for the in-tree -Z dead-fn-elimination flag
• docs/vadim-response-results.md — point-by-point response to the @petrochenkov V1–V9 review (V9 empirical answer)