Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limit completion results #1298

Merged
merged 1 commit into from
Dec 17, 2019
Merged

Conversation

fbricon
Copy link
Contributor

@fbricon fbricon commented Dec 4, 2019

TextEdits need to be computed during the completion call, 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.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 #465

Signed-off-by: Fred Bricon fbricon@gmail.com

@fbricon fbricon force-pushed the limit-completion branch 4 times, most recently from ec32884 to ef1e043 Compare December 13, 2019 11:17
@fbricon fbricon marked this pull request as ready for review December 13, 2019 11:17
@fbricon fbricon changed the title WIP Limit completion results Limit completion results Dec 13, 2019
@fbricon fbricon requested a review from snjeza December 13, 2019 13:14
Copy link
Contributor

@akaroml akaroml left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added some suggestions.

if (i >= p2Length) {
return -1;
}
res = Character.compare(p1.getCompletion()[i], p2.getCompletion()[i]);
Copy link
Contributor

@akaroml akaroml Dec 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

}

private String getSortText(CompletionItem ci) {
return StringUtils.defaultString(ci.getSortText(), "99999999999");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use the SortTextHelper.CELING for consistency?
Its value is 999_999_999.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@fbricon fbricon force-pushed the limit-completion branch 2 times, most recently from 2aa4845 to abb3a2c Compare December 16, 2019 18:07
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 <fbricon@gmail.com>
Copy link
Contributor

@akaroml akaroml left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

completion request should include textEdit according to protocol
4 participants