analysis-stats perf regression

[jonas-schievink]

Looks like the cause is somewhere in the range e315fd...43253c. Unfortunately it's very noisy, so it might be caused by something that is slightly outside of that range.

[lnicola]

Since ripgrep and webrender don't show any change, it might be that rust-analyzer itself just got harder to analyze. But there doesn't seem to be a large code or complexity increase in that range.

[jonas-schievink]

Oh, it's the additional fmt::Debug bounds here: https://github.com/rust-analyzer/rust-analyzer/pull/6094/files#diff-5e1b9043a18996b86f83bba7836c3b97ab88cf3c4834850c62de4f435e483318R26

I actually saw chalk spending a long time proving Debug bounds and mentioned that on Zulip: https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/Poor.20type.20inference.20performance.20on.20chained.20method.20calls

So, seems like a chalk bug.

[flodiebold]

Oh yeah, the problem is that currently Chalk doesn't normalize the associated type projection before trying to prove the bound, which means it has to go through every impl. So with a trait that has a lot of impls like Debug, that can be a big performance problem. rust-lang/chalk#589 should address that, but it's been a long time coming.

[jonas-schievink]

Ah, okay. That explains why it's still fast in general, if proving ConcreteType: Debug doesn't hvae to go through all impls.

[nightkr]

FWIW I've had a regression somewhere between 2edf15a...cb78c40 that makes rust-analyzer nearly unusable (auto-completion takes seconds to show up after I start typing, and when I'm done it slowly chugs through my edits character by character to re-highlight errors, spending about a second per edit) on my laptop (Ryzen 3750H, emacs + lsp-mode, Linux).

Weirdly enough my desktop seems to handle it fine (Ryzen 3900X, but otherwise similar).

It seems to happen for https://github.com/clux/kube-rs and to a lesser degree https://github.com/hyperium/hyper, but not an empty dummy project created by cargo new.

I'll try to see if it seems to match up with your tighter commit range..

[nightkr]

Reverting #6094 from master didn't seem to make a difference for me (and I had a pretty hard time believing it should make a difference for non-RA projects).

43253c5 also seems to still be on the good side for me, so I guess it's an unrelated issue.

[flodiebold]

I opened an issue to keep track of the Chalk issue, but let's close this since it's otherwise not really actionable.