Severe regression in html5ever build time

[michaelwoerister]

The build time of html5ever has gone up by more than 70% for debug builds recently:
http://perf.rust-lang.org/compare.html?start=4745092d608e65ec869c0ebdb27c535f27606ea4&end=6a87289fa4f49b6bdd62f33f69a580026223421f&stat=instructions:u

There are quite a few candidates for introducing this regression in the changeset:
4745092...6a87289

Would anybody from @rust-lang/wg-compiler-performance or @rust-lang/infra care to bisect further?

[michaelwoerister]

The "tuple stress" benchmark is affected even more while most of the other things have improved. Maybe that gives a hint?

[ishitatsuyuki]

My first guess would be quadratic or exponential blowup. Maybe someone can do a perf focus?

[michaelwoerister]

Yes, good idea!

[alexcrichton]

Bisection for tuple-stress points to #50282 (cc @fitzgen)

Before that PR rustc main.rs took ~4s and afterwards I killed it after 2m as I didn't want to wait for it to finish

[alexcrichton]

That may also be the source of the html5ever regression. cargo rustc --lib -- -Z time-passes takes 10s before that commit (the entire cargo rustc time) and 21s afterwards.

[michaelwoerister]

Thanks, @alexcrichton! cc also @oli-obk & @eddyb

[Mark-Simulacrum]

@alexcrichton Could you post instructions for replicating the slow down? Neither @nnethercote or I could reproduce it -- despite running perf on the appropriate commit range locally.

[fitzgen]

So should we revert that PR's commits?

[alexcrichton]

@Mark-Simulacrum sure yeah, using rustup-toolchain-install-master I did the equivalent of:

$ rustup-toolchain-install-master c1168be5360f17516b233be85ebb193bb4e612bf a2726846f6d6280b752019472b6bd791c0752006
$ pwd
/home/alex/code/rustc-perf
$ git rev-parse HEAD
254d28f6181cd5d20cedcd3fa9ae36df847da958
$ time rustc +a2726846f6d6280b752019472b6bd791c0752006 collector/benchmarks/tuple-stress/src/main.rs
rustc +a2726846f6d6280b752019472b6bd791c0752006   4.58s user 0.72s system 100% cpu 5.264 total
$ time rustc +c1168be5360f17516b233be85ebb193bb4e612bf collector/benchmarks/tuple-stress/src/main.rs
^C
rustc +c1168be5360f17516b233be85ebb193bb4e612bf   109.70s user 0.60s system 99% cpu 1:50.31 total

[oli-obk]

We should probably only run the disaggregation pass if the opt level is > 1. That's what's done for the copy prop pass already