Add exported members of all project files in the global completion list

[ghost]

Updated version of #17851

I tested this out in the vscode repository by navigating to actionbar.ts and hitting ctrl-space on an empty line to get completions. Completions time went up from 30 to 50ms, which isn't too bad. (Note that this is after waiting 20 seconds for the project to load.)

However, the length of the output went up from 75054 characters to 476065 -- 6 times as much. This means that "Loading..." will show up for a moment before showing completions. Note that this only happens if no characters have been typed yet and we have to send every completion -- if even a single character has been typed in there is no noticeable delay.

We might want to work on reducing the size of completions output, such as not including sortText every time (it's always 0).

[mhegazy]

@mjbvz we will need a to give this a test to make sure we are not degrading the overall completion experience in VSCode for large projects.. and whether limiting the number of entries would be a possibility.

[mjbvz]

Thanks @jrieken! Yes I forgot about the CompletionList type.

@mhegazy Let's make sure this is tested on the vscode and typescript repos at least. If there are perf isssues, we may have to add a new incomplete flag on CompletionsResponse or similar to tell VSCode to should re-request completions

[mhegazy]

We will hold off on merging this untill we hear back from you then.

[jrieken]

Rule of thumb is that the completion UI, esp. sorting and ranking, is still fast and responsive with ~10000 elements

[mjbvz]

@mhegazy and @andy-ms I just tested a local build of the branch and did not see any performance problems. I also don't see the global completions returned on a empty line however. Is this the expected behavior?

[ghost]

@mjbvz Did you see any completions at all on the empty line?
We might have different subjective standards of what a performance problem is -- I'm judging this by whether I see Loading... at all. Since TypeScript's computational time is only 50ms, it's possible that the delay is due to VSCode having to do work to render all of those completions, so maybe there's something you could do on your side to speed that up.

We had discussed a strategy where on the TypeScript side we would try and filter out just those completions that start with the identifier text -- but it looks like VSCode usually has a more loose way of matching completions, so that's probably better done on the vscode side. If the issue isn't actually the communication between the editor and language server and is actually just rendering time, then there's no problem with doing the filtering in vscode.

[mjbvz]

@andy-ms When triggering on an empty line, I only see the standard global completions currently. Here's a gif of the difference in behavior:

In the first example, I trigged suggestions on an empty line and SettingsDocument is not found. In the second, I start typing which triggers the suggestions after the s has already been entered. This time SettingsDocument is found

[ghost]

@mjbvz Thanks, I've tracked down that behavior to a bug in our filtering completions with startsWith (we were checking if it started with ";"). But see my above comment - maybe we shouldn't have the startsWith call in TypeScript because vscode does more loose completion matching? Is there anyway you could test how long it takes to get the completions from TypeScript vs how long it is taking to render them?

[mjbvz]

@andy-ms I think we should keep the startsWith filtering. This has been the existing behavior for a while, correct?

---

Here's my measurements in the vscode codebase with the latest changes.

Blank line:

ts extension: 51.066ms
suggest e2e: 249.678955078125ms

Start typing:

ts extension: 98.494ms
suggest e2e: 155.81494140625ms

ts extension tracks the time of the completions request within the typescript extension itself. This includes the request to the TS server and receiving the response.

suggest e2e tracks the entire time to compute the completions. This includes the time to ask the ts extension for these completions and processing the response.

[ghost]

This has been the existing behavior for a while, correct?

No, it was added in this PR just for the completions from module exports.

[jrieken]

I wouldn't use startWith as that is a really weak check which prevents any smartness further down the road. Use a check that makes sure every character from the prefix/query text occurs in order in the suggestion text. The in order check could be made optional as we have requests to account for typos, so cno should still match console. Consider that stretch