eclipse-jdtls
compute type arguments directly from declaration signature
To mitigate performance issue mentioned in #1864
Root cause
For every candidate of constructor invocation, toRequiredTypeEdit was called to construct textEdit. Computing type arguments takes long time because of below line:
https://github.com/eclipse/eclipse.jdt.ls/blob/7f393975b11ccfc03b3a5dc13f585855a5885461/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/contentassist/CompletionProposalReplacementProvider.java#L647
Solution
Information about type arguments is already carried in declarationSignature field of the original completion proposal as below. And it's much cheaper by parsing a well-formatted signature.
InternalCompletionProposal@12949 "[CONSTRUCTOR_INVOCATION]{completion:(), declSign:Ljava.util.ArrayList<TE;>;, sign:(Ljava.util.Collection<+TE;>;)V, declKey:, key:, name:ArrayList, replace:[436,436], token:[427,436], relevance:59}"
Below is the call tree after applying this PR.
Let's compare it with https://github.com/eclipse/eclipse.jdt.ls/issues/1864#issue-984648697 , using unit.codeComplete (which we assume is taking a fixed amount of time) to calibrate.
getCompletionItems now takes 0.5x of the time unit.codeComplete takes, and previously it's 2x. Now testing "new S^" in a spring-boot project on my machine, the completion request takes ~150ms overall and unit.codeComplete takes ~100ms, which matches above profiling result.
CI failed for unrelated cases, tracked in https://github.com/eclipse/eclipse.jdt.ls/issues/1869#issuecomment-918959582
https://ci.eclipse.org/ls/job/jdt-ls-pr/2839/console
Took 40 min on basic-mls1s
This time, no failed case, but the same "SIGKILL" error as mentioned in https://github.com/eclipse/eclipse.jdt.ls/issues/1869#issuecomment-914880110