30% cargo target directory size regression between rust 1.96(.1) and 1.97(.1)

[inga-lovinde]

On our codebase (~1M LoC in a workspace with ~700 crates), we noticed a significant cargo target directory size regression after upgrading to Rust 1.97.1.

Examples of what we're observing:

• cargo build --bins --release with default optimization settings (there are no [profile.release] section in our Cargo.toml) and latest mold linker: increase from ~6GB to ~7GB.
• cargo nextest archive (which as I understand simply builds everything with all features in debug profile), with CARGO_INCREMENTAL environment variable set to 1 and RUSTFLAGS environment variable set to -C strip=debuginfo and necessary mold flags, and with debug = 0 in [profile.dev]: increase from ~62GB to ~79GB.
• cargo clippy --all-targets or cargo clippy --bins with CARGO_INCREMENTAL=1 and mold in RUSTFLAGS: no difference between 1.96.1 and 1.97.1 (at ~19GB and ~11GB respectively).

The results are very reproducible; just changing channel in rust-toolchain.toml between 1.96.1 and 1.97.1 (and cleaning cargo target directory so that it's empty) and re-running the command is enough to see the old or the new size. This also reproduces in a clean container based on rust:1.96.1-bookworm or rust:1.97.1-bookworm images (with regular libraries necessary for build installed from regular debian package repository).

Comparing two cargo target directories (for cargo nextest archive example) does not produce any insights; the directory structures are the same, and it's just that every file is suddely 20-50% larger on 1.97.1. debug directory is larger, everything in debug/deps is larger, and everything in debug/incremental/<crate_id>/<id> is larger (including dep-graph.bin and query-cache.bin).

Interestingly, archiving and compressing the target directory with ZSTD_CLEVEL=12 tar --zstd -cf ... produces archives of more or less the same size (~16.5GB), hinting that all that extra disk space used does not actually contain any significant amounts of new information; that the extra data is somewhat redundant from zstd point of view.

So I suspect that maybe this was caused by the change in #151994 . Maybe with the new mangling scheme, somehow our identifiers are so large (and there are so many of them in the output) that on non-incremental release builds they contribute 15% to the size of cargo target dir, and on incremental builds, 30%?

I'm sorry that this is not a very detailed or specific information.

Version it worked on

It most recently worked on: 1.96.1

Version with regression

rustc --version --verbose:

rustc 1.97.1 (8bab26f4f 2026-07-14)
binary: rustc
commit-hash: 8bab26f4f68e0e26f0bb7960be334d5b520ea452
commit-date: 2026-07-14
host: x86_64-unknown-linux-gnu
release: 1.97.1
LLVM version: 22.1.6

@rustbot modify labels: +regression-from-stable-to-stable -regression-untriaged

[inga-lovinde]

After reading https://blog.rust-lang.org/2025/11/20/switching-to-v0-mangling-on-nightly/ , decided to try to enable -C strip=symbols.

Results:

• On 1.96.1, with -C strip=debuginfo: 62GB.
• On 1.96.1, with -C strip=symbols: 53GB (9GB less).
• On 1.97.1, with -C strip=debuginfo: 79GB.
• On 1.97.1, with -C strip=symbols: 62GB (17GB less than without stripping symbols, but still 9GB more than on 1.96.1 with stripping symbols).

[apiraino]

Visited during compiler pre-triage: I wonder if there's anything else we can do to recover these binary size regressions caused by the new v0 mangling

@rustbot label i-compiler-nominated

[apiraino]

Visited during triage on Zulip.

Currently we don't have other actionable for this than tuning strip flag (as pointed out in the blog post), if you have any questions about passing them to cargo, let us know.

We discussed how we could explore in the future other ways to strip symbols - that's open to anyone having bandwidth to tackle the problem - but nothing we can offer right now.

@rustbot label -i-compiler-nominated -i-prioritize +p-medium