WIP: Improve completion performance through caching

[danielhuang]

Contains very poorly written code.

#7542

[danielhuang]

The caching system mostly works with mainly method completions.

[danielhuang]

The main reason tests are failing is the lack of automatic imports. The automatic import is still working in VSCode. scope is currently missing from ImportEdit because ImportEdit does not implement Send, and the only purpose it serves is to provide automatic import tests for completion.

[Veykril]

The automatic import is still working in VSCode. scope is currently missing from ImportEdit because ImportEdit does not implement Send, and the only purpose it serves is to provide automatic import tests for completion.

TIL, I always thought that was required for completion resolving but turns out it isn't. I wonder if would make sense cfg(test) that(To make this Sendable one could lower the SyntaxNode inside of it to a GreenNode and reconstruct that on demand).

That aside, have you benchmarked this(via manual testing), that is has this improved out completion times noticably? This adds a lot of complexity and I believe this currently won't improve completion times too much given most of our issues come from salsa query revalidation. This will also behave rather oddly with flyimport completions given how they currently work I believe, we only kick these off at 3 characters typed as it is right now, and afterwards we can get new completions as we cap the maximum number of flyimport completions we generate, so this cache will limit our completion capabilities quite significantly in this regard.

So while we definitely do want to do some form of caching at some point, given how flyimport currently works for us I am not sure if this is feasible at the moment.
(I apologize for not getting into the matter earlier)

[danielhuang]

This implementation of caching does feel pretty hacky.

That aside, have you benchmarked this(via manual testing), that is has this improved out completion times noticably?

The main purpose of the caching is to prevent typing from causing the completion to "reset". For example, in VSCode, typing a single letter would cause the extension to "recalculate" the completions, which would cause VSCode to stop showing the completions after typing (since the second letter is typed before the calculation finishes). The caching would re-emit the previously calculated completions which would allow VSCode to continue showing the completions.

I've also tried Rust development in CLion (using IntelliJ Rust) and GNOME's Builder (using rust-analyzer). Both of these editors appear to perform this type of caching on the client side (the backend will only perform the calculation a single time after typing .).

[road2react]

what is Caching

[danielhuang]

I've been trying different attempts. I will close this for now.