Performance of CodeAction and InlayHints

[kjeremy]

When opening main.rs from ra_lsp_server I'm seeing the following:

[Trace - 10:25:17 AM] Received response 'textDocument/codeAction - (69)' in 211ms.
[Trace - 10:25:17 AM] Received response 'rust-analyzer/inlayHints - (70)' in 200ms.

These are an order of magnitude higher than other requests.

[matklad]

The reason for this I think is that these are the first thing to trigger the actual analysis. The sutff aft3erwards just gets the analysis from ache

[kjeremy]

Yeah could be. Full trace:

[Trace - 10:32:15 AM] Sending notification 'textDocument/didOpen'.
[Trace - 10:32:15 AM] Sending request 'textDocument/codeAction - (5)'.
[Trace - 10:32:15 AM] Sending request 'rust-analyzer/inlayHints - (6)'.
[Trace - 10:32:15 AM] Sending request 'textDocument/documentSymbol - (7)'.
[Trace - 10:32:15 AM] Received response 'textDocument/documentSymbol - (7)' in 17ms.
[Trace - 10:32:15 AM] Sending request 'textDocument/foldingRange - (8)'.
[Trace - 10:32:15 AM] Received response 'textDocument/foldingRange - (8)' in 1ms.
[Trace - 10:32:15 AM] Sending request 'textDocument/codeLens - (9)'.
[Trace - 10:32:15 AM] Sending request 'textDocument/codeAction - (10)'.
[Trace - 10:32:15 AM] Sending notification '$/cancelRequest'.
[Trace - 10:32:15 AM] Received response 'textDocument/codeAction - (5)' in 211ms. Request failed: canceled by client (-32800).
[Trace - 10:32:32 AM] Received response 'textDocument/codeLens - (9)' in 17449ms.
[Trace - 10:32:48 AM] Received response 'textDocument/codeAction - (10)' in 32824ms.
[Trace - 10:32:48 AM] Received notification 'textDocument/publishDiagnostics'.
[Trace - 10:32:48 AM] Received response 'rust-analyzer/inlayHints - (6)' in 33025ms.
[Trace - 10:32:50 AM] Received notification 'textDocument/publishDiagnostics'.

[codesections]

I am also noticing dramatically higher completion times from main.rs than from other files—and it is not because these completions are the first to trigger analysis.

Here is my detailed test case: When working on my current project, I open a file other than main.rs (e.g., errors.rs). As expected, the very first completion hangs until rust-analyzer has finished loading (about 30 seconds, if I trigger the completion promptly). After that, however, all completions in errors.rs take less than 0.25 seconds.

However, if I navigate to main.rs, completions take over 4 seconds. This time does not improve, including for repeated, identical completions.

I measured these times in Emacs, but I experienced the same issue in VSCode (I didn't record the performance, but it was broadly similar).

I mention the specific project I was working on because I suspect that the number of crates is driving the slowdown. For reference, the project I was working on had 17 direct dependencies in its Cargo.toml, which (according to rust-analyzer) lead to 279 Rust packages for rust-analyzer to chew on.

I tested a bit with smaller projects and did not observer the same slowdown. Please let me know if any other info would be helpful.

[matklad]

Yep, I can reproduce the slowness. Unfortunately the answer is "warp uses generics heavily, and we really spend all that time inferring types" :-( This will be fixed eventually, but we haven't yet got to really optimizing inference/trait solving.

@flodiebold is here any way in which we can cache inference info for dependencies? Would it make sense to make trait_solver_query a constant for dependencies? Or are we only using chalk::Solver for local crate in such cases?

[flodiebold]

is here any way in which we can cache inference info for dependencies? Would it make sense to make trait_solver_query a constant for dependencies? Or are we only using chalk::Solver for local crate in such cases?

The solver is always for the crate in which we're doing type inference, so it should only be there for whatever crate we're currently opening... I guess there could be some ways where we could detect that a trait query can't change because of the orphan rules, but it wouldn't be trivial 🤔

[lnicola]

@kjeremy are you still seeing this? I'm sure there are still performance problems, but it's relatively snappy for me:

requests:
   67 textDocument/codeLens               1ms
*  54 textDocument/onTypeFormatting       2ms
   55 textDocument/completion             27ms
   53 rust-analyzer/inlayHints            29ms
   56 textDocument/semanticTokens/full/delta29ms
   57 completionItem/resolve              0ms
   58 textDocument/foldingRange           0ms
   60 textDocument/documentSymbol         0ms
   59 textDocument/codeLens               1ms
   61 textDocument/codeAction             0ms

@codesections same question. I tried loading up your project and completions in main.rs are in the 30-160 ms range for me.

[kjeremy]

I don't believe so.