Rust: compilation time hit from recent PR

Created on 9 Sep 2018 · 7Comments · Source: rust-lang/rust

Sadly, https://github.com/rust-lang/rust/pull/53949 seems to have been very bad for compilation times. I think we have to back it out until we find a way to do it more efficiently. :(

cc @estebank

I-compiletime P-high T-compiler regression-from-stable-to-nightly

Source

nikomatsakis

Most helpful comment

And here I was, all excited about the latest nll-dashboard results, which showed e.g. html5ever at at 1.01x ratio 😛

nikomatsakis on 9 Sep 2018

😄6

All 7 comments

And here I was, all excited about the latest nll-dashboard results, which showed e.g. html5ever at at 1.01x ratio 😛

nikomatsakis on 9 Sep 2018

😄6

tuple-stress-check:
avg: 9711.2% | min: 6519.9% | max: 18808.1%
avg: 9721.3% | min: 6350.5% | max: 17849.0%
avg: 9692.6% | min: 6351.6% | max: 17734.3%

Woooooooooooooooooooooowwwwww!! :)

michaelwoerister on 9 Sep 2018

And here I was, all excited about the latest nll-dashboard results, which showed e.g. html5ever at at 1.01x ratio

Woooooooooooooooooooooowwwwww!! :)

I feel like I deserve some kind of badge for this ^_^

Sadly, #53949 seems to have been very bad for compilation times. I think we have to back it out until we find a way to do it more efficiently. :(

I'm pretty sure that the check for margins in every close delimiter is to blame. This could be moved to instead collect all the matching delimiter spans and check the left padding _only in the case of mismatched braces_. This should fix the performance regression for all cases, while keeping the behavior on bad code, at the expense of keeping a vec of _all_ braces' opening and closing span (instead of only the "suspicious" ones). I will be in flight until tomorrow afternoon. If the performance regression needs to be fixed before then, please revert the PR, otherwise I'll make the appropriate change (assuming I'm correct).