compilation time hit from recent PR

[nikomatsakis]

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. :(

cc @estebank

[nikomatsakis]

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

[michaelwoerister]

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!! :)

[estebank]

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).

[nagisa]

The corresponding PR has been merged. Should this be closed?

[michaelwoerister]

perf.rust-lang.org looks like it's back to normal again. Thanks for fixing, @estebank!

[estebank]

@michaelwoerister sorry to cause the epic slowdown to begin with :)

[michaelwoerister]

@estebank No worries!