unicode_normalization
benchmark from rustc-perf
is slow
#57718
Labels
I-compiletime
Issue: Problems and improvements with respect to compile times.
The
unicode_normalization
benchmark was just added torustc-perf
: rust-lang/rustc-perf#328Here is the high-level data from Cachegrind for a
Clean-Check
run.The first three entries show that
expand_node
is super-hot:rust/src/librustc/infer/lexical_region_resolve/mod.rs
Lines 217 to 273 in d45bef9
Most of the calls take the
return
on line 241, i.e. thelub == cur_region
comparison succeeds. That explains why<rustc::ty::sty::RegionKind as core::cmp::PartialEq>
shows up as hot.expand_node
is called from a closure withinexpansion
:rust/src/librustc/infer/lexical_region_resolve/mod.rs
Lines 188 to 215 in d45bef9
That closure is passed to
iterate_until_fixed_point
:rust/src/librustc/infer/lexical_region_resolve/mod.rs
Lines 724 to 745 in d45bef9
Most of the calls to
iterate_until_fixed_point
have a tiny number of constraints and iterations. But forunicode_normalization
there are two exceptional calls.The first exceptional call has 30,902 constraints (20,598
VarSubVar
ones followed by 10,304RegSubVar
ones), coming from thismatch
:https://github.com/nnethercote/rustc-perf/blob/47adadaf3541db9382d5fb3cba5ca7c75064219f/collector/benchmarks/unicode_normalization/src/tables.rs#L1788-L3853
It takes 2,064 iterations to process; by the end the constraints list is empty.
The second exceptional call has 55,172 constraints (36,778
VarSubVar
ones followed by 18,394RegSubVar
ones), coming from thismatch
:https://github.com/nnethercote/rustc-perf/blob/47adadaf3541db9382d5fb3cba5ca7c75064219f/collector/benchmarks/unicode_normalization/src/tables.rs#L3855-L7538
It takes 3,682 iterations to process; again, by the end the constraints list is empty.
cc @rust-lang/wg-compiler-performance
The text was updated successfully, but these errors were encountered: