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