Resolve completion item time should be improved

[isidorn]

Hi VS Code PM here 👋

On the VS Code side we investigate the time it takes for various language extension to resolve completion items (the time it takes from user selecting an item in the suggest widget until it is ready). And we found that Volar is second slowest extension.

Could we investigate if there are some perf fixes to be done in this area.

So 90% of the users completion resolving is done only in 160ms.

Thank you 🙏

[johnsoncodehk]

Hi, thanks for contacting me, I'd be more than happy to investigate it, but it lacks context. Would you mind reaching out to me on Discord for a deeper chat? My discord id is johnsoncodehk#0495, thanks!

[isidorn]

@johnsoncodehk sorry I do not have discord.

What context would you like me to provide? This is time for all users in VS Code - based on how much time it takes Volar to resolve a completion item. Here's where we log that event in VS Code https://github.com/microsoft/vscode/blob/ac34ea3a6e3334c2bfb01f5c234863747e07f18c/src/vs/editor/contrib/suggest/browser/suggestController.ts#L516

You can follow the resolveDuration to get more insights.
This maps to the time your extension needs to complete the resolveCompletionItem call https://github.com/microsoft/vscode/blob/ac34ea3a6e3334c2bfb01f5c234863747e07f18c/src/vscode-dts/vscode.d.ts#L4689

[johnsoncodehk]

Do not mind! Let me illustrate Volar cost in resolveCompletionItem, it has 4 main parts.

1. Overhead of Volar virtual file: For resolveCompletionItem, it mainly performs mapping from vue position to virtual file position, and maps virtual file completion result back to vue file. The cost of this part is negligible.
2. "Improper use of TS" overhead: If Volar does not correctly port tsserver's auto import caching and DocumentRegistry logic, the performance of TS LanguageService will be greatly affected. (Other than Astro which already adopted Volar.js, vue.volar is the only one of all meta-freamworks that correctly supports this)
3. The cost of TS executing getCompletionEntryDetails(): This is a part that Volar cannot control, and it occupies most of the time of resolveCompletionItem (code located at: https://github.com/volarjs/services/blob/0f83a43ca82ae2f7e2c38ca91357da448879473c/packages/typescript/src/features/completions/resolve.ts#L39)
4. The size of node_modules & source files: Specifically, this mainly refers to the number of lines of code in project files and all .d.ts files in node_modules, which directly affects the work that getCompletionEntryDetails() needs to do. It is worth mentioning that we recently released TS Memory Visualization feature, and found that a UI framework element-plus generated abnormal scale .d.ts files due to some bugs (such as https://cdn.jsdelivr.net/npm/element-plus@2.3.8/es/components/autocomplete/index.d.ts), which causes TS performance to be greatly reduced. Since element-plus is widely adopted in Vue ecosystem, this is an important factor affecting the performance benchmarks collected by VSCode.

---

I'd like some context to troubleshoot the points above.

1. Is there any significant difference between the data of Volar 1.8.5 and 1.8.4? We ported the auto import caching logic of tsserver very early, but TS DocumentRegistry was not supported correctly until 1.8.5.
2. Can you share the data for vscode.typescript-language-features, astro-build.astro-vscode <= 2.0.18 & 2.1.1, octref.vetur? I will be able to make some judgments by cross-contrasting.

[isidorn]

Thanks for providing more details. Let me answer your questions:

1. No big change between 1.8.5 and 1.8.4
   

2. Here's the data with typescript and vetur
   

Here's astro-build.astro-vscode

[johnsoncodehk]

2. "Improper use of TS" overhead

I would like to correct a bit, this has a big effect on provideCompletionItems but seems almost no effect on resolveCompletionItem.

Thanks for the data! I'll schedule a time to investigate it in depth.

[johnsoncodehk]

Hi @isidorn! We fixed a certain performance issue on the Volar side (volarjs/volar.js#66) and it may be related. Could you share the data of vue.volar 1.8.15 and 1.8.16 and see if any differences?

[isidorn]

@johnsoncodehk great that you worked on improving the performance.

Overall no big changes. I no longer have the query to look per extension version - apologies.

[johnsoncodehk]

Don't worry, thanks for your help! The problem will be solved in 2.0 anyway, because TS completion will be based on TS Plugin instead of our own LSP server to avoid duplicate TS overhead.