Auto merge of #136593 - lukas-code:ty-value-perf, r=oli-obk
valtree performance tuning Summary: This PR makes type checking of code with many type-level constants faster. After https://github.com/rust-lang/rust/pull/136180 was merged, we observed a small perf regression (https://github.com/rust-lang/rust/pull/136318#issuecomment-2635562821). This happened because that PR introduced additional copies in the fast reject code path for consts, which is very hot for certain crates:6c1d960d88/compiler/rustc_type_ir/src/fast_reject.rs (L486-L487)
This PR improves the performance again by properly interning the valtrees so that copying and comparing them becomes faster. This will become especially useful with `feature(adt_const_params)`, so the fast reject code doesn't have to do a deep compare of the valtrees. Note that we can't just compare the interned consts themselves in the fast reject, because sometimes `'static` lifetimes in the type are be replaced with inference variables (due to canonicalization) on one side but not the other. A less invasive alternative that I considered is simply avoiding copies introduced by https://github.com/rust-lang/rust/pull/136180 and comparing the valtrees it in-place (see commit:9e91e50ac5
/ perf results: https://github.com/rust-lang/rust/pull/136593#issuecomment-2642303245), however that was still measurably slower than interning. There are some minor regressions in secondary benchmarks: These happen due to changes in memory allocations and seem acceptable to me. The crates that make heavy use of valtrees show no significant changes in memory usage.
This commit is contained in:
commit
c241e14650
15 changed files with 159 additions and 130 deletions
|
@ -2161,7 +2161,7 @@ impl<'tcx> dyn HirTyLowerer<'tcx> + '_ {
|
|||
did,
|
||||
path.segments.last().unwrap(),
|
||||
);
|
||||
ty::Const::new_value(tcx, ty::ValTree::zst(), Ty::new_fn_def(tcx, did, args))
|
||||
ty::Const::zero_sized(tcx, Ty::new_fn_def(tcx, did, args))
|
||||
}
|
||||
|
||||
// Exhaustive match to be clear about what exactly we're considering to be
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue