Performance issues with code completion

[kaloyan-raev]

The issue from user point of view is that sometimes there is a big delay (5-10 seconds) between invoking code completion and showing the list with proposals. An acceptable delay would be less than a seconds, and if close to a second, not to have the delay on every keystroke.

After spending some time examining how code completion works both in VS Code and Eclipse Che, I can say that the performance issue in Che is not observed in VS Code using the same language server. So, we should look for optimizing the code completion mechanism on Che side rather than in the specific language servers.

Issue 1. Che floods the DOM tree with HTML elements for each completion proposal item.

It's a common case the language server to return a completion list with 5,000-10,000 items and even more. Currently, Che adds a <li> element to the completion proposal widget for each proposal item. And each <li> element includes several <span> elements for coloring. This flood to the DOM tree is the major contributor to the big delay.

Instead of this wasteful generation of thousands of HTML elements, the completion proposal widget should have a fixed number of <li> elements that cover the visible area plus some buffer above and below it. These <li> elements should be reused as the user scrolls the list up and down. I am not sure at the moment how this can be achieved with GWT, my knowledge is still pretty limited. As a low hanging fruit, we can just limit the maximum number of items displayed in the completion proposal widget to some reasonable number (e.g. 300).

Issue 2. Che does not respect the CompletionList.isIncomplete flag.

This flag tells the client if further typing would return different result. If the flag is false, i.e. the list is "complete" then the client should not send another completion request to the server, but just do additional filtering on the result from the previous request. Respecting the isIncomplete flag would avoid sending unnecessary completion requests on every key stroke.

Issue 1 is the more severe one and affects not only the code completion with language servers, but also the code completion in general, e.g. it affects the Java code completion.

[TylerJewell]

This analysis is quite good. @bmicklea - let's assign this for M7 or M8. I think that these improvements are going to be universally felt, and I suspect that they are not extremely difficult. Is this @vparfonov or @evidolob for an initial implementation?

[bmicklea]

@vparfonov please assign this to someone for the current or next sprint.

[TylerJewell]

Maybe next sprint - certainly not this sprint. We need to think this through and look at for M7 or M8. It's a great improvement, and probably necessary to finish before 5.0 GA.

[bmicklea]

@vparfonov - please add status and sprint labels

[kaloyan-raev]

Just to let you know that I started working on this topic. I did some research and I have a good idea how to resolve issue 1.

[kaloyan-raev]

I prepared PR #3146 to address Issue 1.

I will take care for issue 2 in another PR.

[kaloyan-raev]

I have a patch for Issue 2 in the same PR #3146.

I decided to include it in the same PR, because the positive effect of fixing issue 2 is not really visible without having the fix for issue 1.

I noticed another small issue. There is some noticeable flickering of the content assist widget between keystrokes. I will work on it too. However, most of the work on this topic is done and I would appreciate some initial review.