improve template interpolation features performance when no changes to the file

• I have searched through existing issues

Feature Request

Hi, First of all, thanks for the great works you guys put into it. The template interpolation feature really makes the developer experience way better and it’s a good boost to productivity. But the performance is really not very good sometimes. I would like to help out and make it better.

I’ll focus on the performance of template interpolation features performance when no changes to the file in this issue. That is features like hover, completion resolve, go to definition, and find references. Especially the second request. I have done some investigation using my local clone version. Here’s what I found out and think can make the performance better:

The problems

vueInfoService.getInfo

https://github.com/vuejs/vetur/blob/c26d51c342e495c27ab52dd39e22c7e68b6c6ab2/server/src/services/vueInfoService.ts#L105

This method is very demanding it often took more than 500ms on my machine. Besides the performance of this method, what strange to me is that the vueFileInfo map here seems like a kind of cache but it’ll always get updated when getInfo is called. Furthermore, the stored info doesn’t get removed when the document is closed or deleted in the file system, so it’s a sort of memory leak. I think we could remove the map here.

https://github.com/vuejs/vetur/blob/85eecb3ada0a1d1bcdd916e2fa378f3fd708063d/server/src/modes/script/componentInfo.ts#L87

The most demanding part of vueInfoService.getInfo seems to be this line. Analyzing the type afterward isn’t that demanding. I notice typescript does cache the type checker result here. When typescript cache the type it runs significantly faster. So the problem is mainly on why typescript won’t use the cached version. Once that’s resolved. Most of the features that use this method might have a good boost in performance.

Auto import, on the other hand, the implementation makes the script version mismatch on every resolve request. Thus typescript would always analyze it again. We probably need to find another way to improve it. I wonder if we can make the mockDoc here different than the actual script doc.

serviceHost.updateCurrentVirtualVueTextDocument

https://github.com/vuejs/vetur/blob/c26d51c342e495c27ab52dd39e22c7e68b6c6ab2/server/src/services/typescriptService/serviceHost.ts#L194

The version of the virtual vue file bumps whenever the function is called. This makes typescript analyze the type again. It seems to also affect the language service the script section used. And it seems to be the main problem of the interpolation performance. Once I commented out the version bump, most of the feature is way faster. I think we can use the version of TextDocument to avoid bumping when not necessary. But always update ChildComponentsInfo in case the dependent component is updated.

TL;DR

From my understanding/investigation, the main problem is that the version of the virtual vue file in the ServciceHost bumps every time. I think we should use the TextDoucment.version to check if we should bump the version. So that typescript won’t do the type analysis again. And the vueFileInfo map in the vueInfoService doesn’t get used and seems like it can be removed.

Feel free to point out what I missed or what I understand incorrectly. I can help to implement what I mention above. But I think it would be better to have an issue to discuss it first.

[jasonlyu123]

Sorry, I can’t get the profiler working. The project I encounter slow performance is a v2 vue typescript project with composition API and typescript strict mode enabled. Some of the components need more than 1s for go to definition. I’ll see if I can provide a simple repro. But I guess it’s just the typing being too complex so it took quite some time for typescript to fully analyze the type. With that said, once the typescript uses the cached type to process language feature, it really just run much faster. At least it’s more responsive when reading the codebase.

[yoyo930021]

But I think a bigger problem about memory when a file is deleted is probably the typescript source file object and script snapshot object in the serviceHost.

I think it’s necessary because they are interdependent. VSCode’s built-in TS support does exactly the same thing.

Provide a profile, we can study it more simply. https://github.com/vuejs/vetur/blob/master/.github/PERF_ISSUE.md I have not yet encountered the new version of the slow problem.

The parts I expect to refactor:

• New TS files can be added efficiently in TypeScript language service.
• Most unnecessary updates can be reduced.
• Provide syntax mapping to TS files.