7% regression in compile time of tuple-stress benchmark

[alexcrichton]

According to perf.rust-lang.org graphs #44275 caused a ~8% regression in compile time for this benchmark

cc @eddyb (an old nemesis!)

[eddyb]

Yeah, we knew it would take a hit, but without absolute graphs it didn't seem that bad and we just took the risk.

cc @nikomatsakis Do you know of any caching missing here? We do cache the result of evaluation, is this just the cost of renormalizing over and over again?

[nikomatsakis]

@eddyb I'm not sure! Would have to profile I guess.

[nikomatsakis]

triage: P-high

Calling this P-high until we decide if (a) it is isolated or has a pervasive effect and (b) if we know the cause and can readily fix. It'd be great for someone to do some comparative profiling!

[nikomatsakis]

Note: the sources to the benchmark can be found in https://github.com/rust-lang-nursery/rustc-benchmarks

[eddyb]

I believe this might be src/librustc_passes/consts.rs at fault, since it evaluates everything in there, and it's probably interning ty::Const, not any of the deferred array length evaluation changes.
All of this should get better with miri, I would think, and I expect the effect to be isolated.

[nikomatsakis]

Based on @eddyb's comment, lowering priority until miri is merged.

triage: P-low

[Mark-Simulacrum]

Benchmarks are actually here: https://github.com/rust-lang-nursery/rustc-perf/tree/master/collector/benchmarks

[michaelwoerister]

Discussed in triage. Closing since there isn't anything actionable here really.