backtraces from debug assertion rustc are very slow

[matthiaskrgr]

given an ice like

fn main() {
    break rust;
}

running rustc on it and getting the backtrace takes around 0.072 seconds.

with debug assertions, it takes around 6.5 seconds which is around 90 times slower which is surprising.
I don't know since when this is happening but my gut says its probably recent.

There is a noticeable pause after

thread 'rustc' (482933) panicked at /rustc-dev/f10db292a3733b5c67c8da8c7661195ff4b05774/compiler/rustc_hir_typeck/src/lib.rs:697:10:
Box<dyn Any>
stack backtrace:

right before it prints the actual backtraces 🤔

timings:

time:   0.000; rss:  112MB ->  114MB (   +2MB)	parse_crate
time:   0.000; rss:  122MB ->  123MB (   +1MB)	crate_injection
time:   0.004; rss:  123MB ->  134MB (  +11MB)	expand_crate
time:   0.004; rss:  123MB ->  134MB (  +11MB)	macro_expand_crate
time:   0.000; rss:  134MB ->  135MB (   +1MB)	AST_validation
time:   0.000; rss:  135MB ->  135MB (   +0MB)	compute_effective_visibilities
time:   0.000; rss:  135MB ->  135MB (   +0MB)	finalize_macro_resolutions
time:   0.021; rss:  135MB ->  166MB (  +30MB)	late_resolve_crate
error[E0425]: cannot find value `rust` in this scope
 --> a.rs:2:11
  |
2 |     break rust;
  |           ^^^^ not found in this scope

time:   0.000; rss:  166MB ->  166MB (   +0MB)	resolve_report_errors
time:   0.022; rss:  135MB ->  166MB (  +31MB)	resolve_crate
time:   0.000; rss:  169MB ->  170MB (   +0MB)	looking_for_entry_point
time:   0.000; rss:  170MB ->  170MB (   +0MB)	check_externally_implementable_items
time:   0.000; rss:  170MB ->  170MB (   +0MB)	looking_for_derive_registrar
time:   0.000; rss:  170MB ->  170MB (   +0MB)	unused_lib_feature_checking
time:   0.000; rss:  169MB ->  170MB (   +0MB)	misc_checking_1
time:   0.002; rss:  170MB ->  178MB (   +8MB)	coherence_checking
error[E0268]: `break` outside of a loop or labeled block
 --> a.rs:2:5
  |
2 |     break rust;
  |     ^^^^^^^^^^ cannot `break` outside of a loop or labeled block

error: internal compiler error: It looks like you're trying to break rust; would you like some ICE?
 --> a.rs:2:5
  |
2 |     break rust;
  |     ^^^^^^^^^^
  |
  = note: the compiler expectedly panicked. this is a feature.
  = note: we would appreciate a joke overview: https://github.com/rust-lang/rust/issues/43162#issuecomment-320764675
  = note: rustc 1.99.0-nightly (f10db292a 2026-07-07) running on x86_64-unknown-linux-gnu
  = note: compiler flags: -Z time-passes


thread 'rustc' (483179) panicked at /rustc-dev/f10db292a3733b5c67c8da8c7661195ff4b05774/compiler/rustc_hir_typeck/src/lib.rs:697:10:
Box<dyn Any>
stack backtrace:
   0:     0x7f11f7dff9c0 - std[c8053079d20a6ade]::backtrace_rs::backtrace::libunwind::trace
                               at /rustc/f10db292a3733b5c67c8da8c7661195ff4b05774/library/std/src/../../backtrace/src/backtrace/libunwind.rs:117:9
   1:     0x7f11f7dff9c0 - std[c8053079d20a6ade]::backtrace_rs::backtrace::trace_unsynchronized::<std[c8053079d20a6ade]::sys::backtrace::_print_fmt::{closure#1}>
                               at /rustc/f10db292a3733b5c67c8da8c7661195ff4b05774/library/std/src/../../backtrace/src/backtrace/mod.rs:66:14
...
...
...
 141:     0x7f11f7dfb4df - <std[c8053079d20a6ade]::sys::thread::unix::Thread>::new::thread_start
                               at /rustc/f10db292a3733b5c67c8da8c7661195ff4b05774/library/std/src/sys/thread/unix.rs:123:17
 142:     0x7f11f1c981b9 - <unknown>
 143:     0x7f11f1d1d21c - <unknown>
 144:                0x0 - <unknown>

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: please make sure that you have updated to the latest nightly

note: please attach the file at `/tmp/im/bt/rustc-ice-2026-07-08T18_33_46-483177.txt` to your bug report

note: rustc 1.99.0-nightly (f10db292a 2026-07-07) running on x86_64-unknown-linux-gnu

note: compiler flags: -Z time-passes

query stack during panic:
#0 [typeck_root] type-checking `main`
#1 [analysis] running analysis passes on crate `a`
end of query stack
time:   6.153; rss:  170MB -> 1946MB (+1776MB)	type_check_crate
error: aborting due to 3 previous errors

Some errors have detailed explanations: E0268, E0425.
For more information about an error, try `rustc --explain E0268`.

[matthiaskrgr]

hmm, perf top:

  10,33%  librustc_driver-6712db3059a703cf.so             [.] miniz_oxide::inflate::core::decompress_fast
   2,80%  librustc_driver-6712db3059a703cf.so             [.] miniz_oxide::inflate::core::apply_match

[matthiaskrgr]

maybe this is related to #158169 ? cc @Kobzol

[matthiaskrgr]

RUST_BACKTRACE=0 gets it down to ~3 seconds which is a bit better but seems way to much for NOT printing a backtrace at all 😅

[Kobzol]

Oh yes, this is most likely caused by #158169. It seems like decompressing the zlib-compressed DWARF debuginfo is not free :)

I wonder if we could use zlib-rs in backtrace to make the zlib decompression (much?) faster? @workingjubilee @folkertdev What do you think?

[folkertdev]

I´d be all for it

[Kobzol]

Or I wonder if we could just use zstd. It is somehow present in the library, but seems like behind a feature, I'm not sure if it enabled anywhere (?). Anyway, I'll try to use zlib-rs.

[bjorn3]

with debug assertions, it takes around 6.5 seconds

Is that with debug assertions for the standard library? miniz_oxide has a bunch of debug assertions in the hot path. You could try disabling debug assertions for miniz_oxide.

zstd is not enabled for the standard library for code size reasons I believe.

[workingjubilee]

It could be enabled, but I wasn't able to persuade myself that we should take another large code size hit by default for all Rust programs without having the team discuss it, and then for a variety of reasons my brain failed to connect the neurons to get to "so ask the team to discuss it?"

[workingjubilee]

Hello library team. I am asking you if we should endure a code size hit on all Rust programs which may use DWARF in their backtraces in exchange for all Rust programs being able to decode zstd-compressed debuginfo in their backtraces. It is unclear what this does in terms of code size to various sizes of programs. I believe for sufficiently large ones it is positive. Well, strictly speaking it's negative as it might reduce it. But I do believe the baseline does become higher.

cc @khuey

There are alternatives (e.g. binding against the C zstd library via FFI) but this then also adds a load-time penalty to, again, all Rust programs, and for a variety of reasons I was less able to persuade myself that was a good idea either.

@rustbot label: I-libs-nominated

[Kobzol]

Just noting that zlib-rs is a pure Rust rewrite of zlib that is super fast and production ready (and maintained by a t-compiler member, Folkert), no FFI needed. I think that would be a good alternative to zstd. I'll share results once I get it integrated in backtrace.