Move inlayHints LSP request to "resolve" or range pattern for perf

[kjeremy]

It may make sense to split the inlay hints LSP request into two:

inlayHints which would compute where hints would go.
inlayHints/resolve which would compute the actual hints.

I imagine this would work similar to codeLens/resolve which can dramatically speed up scrolling. We could also follow a viewport model like semantic token ranges.

[matklad]

Yeah, I feel pull-based range model will make the most sense.

[Veetaha]

Why don't we make inlayHints push-based instead, i.e. send notifications like we did/do with publishDecorations?

[Veetaha]

I imagine inlayHints are decoration themselves ...

[matklad]

It's an open question what is the best way to synchronize such things: microsoft/vscode-languageserver-node#576 (comment)

The obvious drawback of push-based model is that it doesn't work with viewport optimization

[kjeremy]

Configuration has also moved to a pull based model (see microsoft/language-server-protocol#676). In general the LSP is evolving in that direction.

[matklad]

Configuration is communicated in the opposite direction though, so it's not really a good example in this case :)

[kjeremy]

True!

[Veetaha]

Viewport optimization is quite questionable (if you mean sending requests only for hints withing the visible file range?), because the user scrolls the file and moves around quite frequently, it would be a hell to cache all this stuff and at the end of the day this will result into making more small requests instead of issuing one big.

[matklad]

To not repeat myself, see microsoft/vscode#86415 (comment) for why I think range optimization is essential for good performane

…

On Mon, 2 Mar 2020 at 14:13, Veetaha ***@***.***> wrote: Viewport optimization is quite questionable (if you mean sending requests only for hints withing the visible file range?), because the user scrolls the file and moves around quite frequently, it would be a hell to cache all this stuff and at the end of the day this will result into making more small requests instead of issuing one big. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3394>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANB3M4KGTO5CYHTT3LIBNLRFOWIZANCNFSM4K7TG6QQ> .

[matklad]

well, it's not essential, in a sense that modern CPUs are crazily fast and can plow though almost any amount of work in no time. It is important optimization, because it cuts O(N) work to O(1) work. On Mon, 2 Mar 2020 at 14:21, Aleksey Kladov <aleksey.kladov@gmail.com> wrote:

…

To not repeat myself, see microsoft/vscode#86415 (comment) for why I think range optimization is essential for good performane On Mon, 2 Mar 2020 at 14:13, Veetaha ***@***.***> wrote: > Viewport optimization is quite questionable (if you mean sending requests > only for hints withing the visible file range?), because the user scrolls > the file and moves around quite frequently, it would be a hell to cache all > this stuff and at the end of the day this will result into making more > small requests instead of issuing one big. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#3394>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AANB3M4KGTO5CYHTT3LIBNLRFOWIZANCNFSM4K7TG6QQ> > . >

[Veetaha]

@kjeremy , I've looked a bit into codelens and I don't see how we can apply the resolve pattern to inlay hints. Maybe I don't get the docs (since it is quite sparse), but we have no command or no other thing to resolve for inlays lazily from my viewpoint

[kjeremy]

For the range approach (instead of resolve) maybe we could use this as inspiration: https://github.com/microsoft/vscode/blob/f74e473238aca7b79c08be761d99a0232838ca4c/src/vs/editor/contrib/viewportSemanticTokens/viewportSemanticTokens.ts