Limit completion results #1298
Merged
Limit completion results #1298
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fbricon
force-pushed
the
limit-completion
branch
from
e156a5b
to
e6eedde
Compare
fbricon
force-pushed
the
limit-completion
branch
4 times, most recently
from
ec32884
to
ef1e043
Compare
fbricon
force-pushed
the
limit-completion
branch
from
ef1e043
to
4402722
Compare
snjeza
approved these changes
Dec 13, 2019
akaroml
reviewed
Dec 16, 2019
| if (i >= p2Length) { | ||
| return -1; | ||
| } | ||
| res = Character.compare(p1.getCompletion()[i], p2.getCompletion()[i]); |
There was a problem hiding this comment.
Can we cache the result of getCompletion() with a variable outside the for loop? The implementation of getCompletion is pretty complex in org.eclipse.jdt.internal.codeassist.InternalCompletionProposal and calling it in each iteration looks expensive.
| } | ||
|
|
||
| private String getSortText(CompletionItem ci) { | ||
| return StringUtils.defaultString(ci.getSortText(), "99999999999"); |
There was a problem hiding this comment.
Can we use the SortTextHelper.CELING for consistency?
Its value is 999_999_999.
testforstephen
approved these changes
Dec 16, 2019
fbricon
force-pushed
the
limit-completion
branch
2 times, most recently
from
2aa4845
to
abb3a2c
Compare
TextEdits need to be computed during the completion call, but this can be extremely slow when a large number of results is returned. This change tries to mitigate the issue by returning a partial result list and marking the results as incomplete. Smaller payload means computing Textedits is now more affordable. Hopefully the UX should be improved as well since completion queries will return faster too. The number of completion results is configurable with the java.completion.maxResults preference (defaults to 50). Setting 0 will disable the limit and return all results. Be aware the performance will be very negatively impacted as textEdits for all results will be computed eagerly (can be thousands of results). Fixes eclipse-jdtls#465 Signed-off-by: Fred Bricon <[email protected]>
fbricon
force-pushed
the
limit-completion
branch
from
abb3a2c
to
e04188e
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TextEdits need to be computed during the
completioncall, but this can be extremely slow when a large number of results is returned. This PR tries to mitigate the issue by returning partial result lists and marking the results as incomplete. Smaller payload means computing Textedits is now more affordable. Hopefully the UX should be improved as well since completion queries will return faster too.The number of completion results is configurable with the
java.completion.maxResultspreference (defaults to 50). Setting 0 will disable the limit and return all results. Be aware the performance will be very negatively impacted as textEdits for all results will be computed eagerly (can be thousands of results).Fixes #465
Signed-off-by: Fred Bricon [email protected]