Sometimes Vetur is still very slow

[lanyizi]

• I have searched through existing issues
• I have read through docs
• I have read FAQ

Info

• Platform: Windows
• Vetur version: 0.26.1
• VS Code version: 1.48.1

Problem

I've seen related issues like #1272 talking about calls to synchronizeHostData. I did not dig in too much, but I found that when validating sources and templates, calls such as getSemanticDiagnostics may call synchronizeHostData internally (link), and by a rudimentary profiling it looks like each validation will took ~300ms on my computer. When I'm writing code, js and template will be validated separately, so they might take something like 500 or 600ms in total.
I'm not sure if that's the cause of the issue since I didn't do an accurate profiling, but probably it will help.

vetur/server/src/modes/template/interpolationMode.ts

Line 72 in 53ee527

const rawTemplateDiagnostics = templateService.getSemanticDiagnostics(templateFileFsPath);

vetur/server/src/modes/script/javascript.ts

Line 118 in 2e32351

...service.getSemanticDiagnostics(fileFsPath)

[octref]

Can you attach a profile? If not, can you validate your hypothesis by

• cloning
• return [] eagerly here:

  vetur/server/src/modes/script/javascript.ts

  Line 110 in a6ce17e

  const { scriptDoc, service } = updateCurrentVueTextDocument(doc);

• compiling the server
• test by configuring vetur.dev.vlsPath to absolute path of your local modified /server

[lanyizi]

Tried to return [] eagerly in both javascript.ts and interpolationMode.ts. Vetur is still quite slow, but I can feel that the speed of suggestions (for example when I type this. and wait for the suggestions of the component data members / props / methods) has increased significantly.
CPU-20200827T000556.534Z.cpuprofile.txt

[yoyo930021]

I've studied this side.
I find that typescript language service rebuilds program every time.
Normally, we shouldn't have to rebuild program every time.

Maybe getProjectVersion function can help us to improve this.
https://github.com/microsoft/TypeScript/blob/master/src/services/services.ts#L1281

[lanyizi]

I've just found an old buried pull request which might be useful... #1141

[Eurkidu]

I want to provide some information

Platform: macos
Vetur version: 0.27.3
VS Code version: 1.50.0-insider (same in 1.49.0)

In my typescript project, performance problems have bothered me for a long time, and I checked a lot of performance related problems, such as #2163 and #2150

#2150 (comment)
Like @borie88 said, in the typescript project, just open the project, it can be used normally for a period of time, and then it will become slower and slower, slower and slower. I haven't figured it out before. The experience is just after using it for a period of time. Will slow down. Now I found a way to directly reproduce this performance problem.

The reproduction method is as follows

1. Restart vocode
2. In my project, I perform a type of global replacement, this involves 30 files, and then this operation will be executed for about 60-70 seconds, an average of more than 2 seconds for a file
   At this time, you will get the save and wait Eslint popup described like Getting code actions from ''Vetur', 'Eslint'' takes too long!  #2150

The profile of this operation is as follows

But I can’t save this, because one click save, chrome dev tools will crash directly

After this replacement process, vetur enters the slow mode, all operations will become very slow

For example, for this type of automatic completion prompt, the corresponding prompt box will pop up about 15-20 seconds after entering the point

This is the cpuprofile for this operation
CPU-20200915T105122.cpuprofile.zip

Then after restarting vscode, the same operation will become faster, just like this

Let me talk about my thoughts first

I think that every save operation will generate typescript type snapshot or something, because during the batch replacement operation, I observed that the memory of the vetur server has been changing drastically, from 160mb to more than 400mb, and then back to 160mb , 4-5mb growth per second. Then a large number of snapshots caused the subsequent overall slowdown.

Because through this recurring operation, I found that the running of vuter on the typescript project will become slow as the number of saves increases, and then I can only restart vscode to solve the problem

Vetur is a very good plugin. I like it very much. Recently I started to write Vue projects with typescript, but this performance problem bothered me very much. I had to write code for a while and restart vscode. I hope someone can help solve this Question. Thank you very much

If you want me to provide more information, please feel free to reply to me, I will see

[yoyo930021]

I want to provide some information

Platform: macos
Vetur version: 0.27.3
VS Code version: 1.50.0-insider (same in 1.49.0)

In my typescript project, performance problems have bothered me for a long time, and I checked a lot of performance related problems, such as #2163 and #2150

#2150 (comment)
Like @borie88 said, in the typescript project, just open the project, it can be used normally for a period of time, and then it will become slower and slower, slower and slower. I haven't figured it out before. The experience is just after using it for a period of time. Will slow down. Now I found a way to directly reproduce this performance problem.

The reproduction method is as follows

1. Restart vocode
2. In my project, I perform a type of global replacement, this involves 30 files, and then this operation will be executed for about 60-70 seconds, an average of more than 2 seconds for a file
   At this time, you will get the save and wait Eslint popup described like Getting code actions from ''Vetur', 'Eslint'' takes too long!  #2150

The profile of this operation is as follows

But I can’t save this, because one click save, chrome dev tools will crash directly

After this replacement process, vetur enters the slow mode, all operations will become very slow

For example, for this type of automatic completion prompt, the corresponding prompt box will pop up about 15-20 seconds after entering the point

This is the cpuprofile for this operation
CPU-20200915T105122.cpuprofile.zip

Then after restarting vscode, the same operation will become faster, just like this

Let me talk about my thoughts first

I think that every save operation will generate typescript type snapshot or something, because during the batch replacement operation, I observed that the memory of the vetur server has been changing drastically, from 160mb to more than 400mb, and then back to 160mb , 4-5mb growth per second. Then a large number of snapshots caused the subsequent overall slowdown.

Because through this recurring operation, I found that the running of vuter on the typescript project will become slow as the number of saves increases, and then I can only restart vscode to solve the problem

Vetur is a very good plugin. I like it very much. Recently I started to write Vue projects with typescript, but this performance problem bothered me very much. I had to write code for a while and restart vscode. I hope someone can help solve this Question. Thank you very much

If you want me to provide more information, please feel free to reply to me, I will see

I will study it when free.
You can try #2328 PR. Maybe improve part of the problem.

I think we can provide a VSCode command for restart Vetur LSP.
So no need to restart VSCode everytime.

[Eurkidu]

I will study it when free.
You can try #2328 PR. Maybe improve part of the problem.

I think we can provide a VSCode command for restart Vetur LSP.
So no need to restart VSCode everytime.

@yoyo930021 Thank you for your attention to this issue
I read #2328 PR, is this a statistic about nodeModuleSnapshots? I will try to test this statistic

Recently I cloning vetur and did some tests

First of all, I checked the profile I got before, and I saw that the doValidate function was called many times, and it took a long time

In addition to my usual experience, when the vetur is running slowly, if you quickly type in a string of unformatted code that will report an error, the formatting error prompt is obviously delayed from your operation, and the execution of the formatting error prompt is completed. Before, all other operations, such as saving, code hints, would be blocked

So I started with this function, I tried

vetur/server/src/services/vls.ts

Line 495 in 2e32351

doValidate(doc: TextDocument): Diagnostic[] {

In the first line of this function directly return []
Then I tested it locally, and I found that everything became very fast, including the replacement of more than 30 files. Of course, I only tested for a while, because all error verification was turned off, so typing in any code There is no error prompt, but all code prompts are complete and fast

Next, I found that this function calls the doValidation function for specific verification operations. I searched for the doValidation function in the project, and I found that it is roughly composed of 3 parts
script

vetur/server/src/modes/script/javascript.ts

Line 109 in 2e32351

doValidation(doc: TextDocument): Diagnostic[] {

style

vetur/server/src/modes/style/index.ts

Line 59 in 2e32351

doValidation(document) {

template

vetur/server/src/modes/template/index.ts

Line 50 in 2e32351

doValidation(document: TextDocument) {

I tested these three parts separately. In the first line of the function, directly return []
In the tests of script and style, I found that there is no significant effect change
In the test of template, I found that return [] has significantly improved the speed
Then the verification of template is composed of 2 parts

vetur/server/src/modes/template/index.ts

Line 51 in 2e32351

return this.htmlMode.doValidation(document).concat(this.vueInterpolationMode.doValidation(document));

One part is htmlMode, part is vueInterpolationMode
After testing the two parts separately, I found that when the doValidation of vueInterpolationMode is disabled like this

return this.htmlMode.doValidation(document)

Performance has been significantly improved, at least the code prompt will basically not be stuck
Of course, in this way, the above code error prompt of template is gone, but compared with the code prompt, this is still acceptable.

If you directly set vetur.experimental.templateInterpolationService to false, there will be no code hints on template. This kind of experience is meaningless for developing with typescript. Now I have turned off template locally. Error checking, but retains other field prompts and other functions

So if this performance problem cannot be solved temporarily, I hope I can temporarily provide an option to turn off error checking on template @octref
Just like #2150 (comment)

After a period of use, I found that the performance of vetur will still slow down over time, but it is much better than before. When it is slow, the code prompt takes about two or three seconds instead of the previous 20- 30 seconds, but I think this effect is acceptable for the time being, because before I used to restart vscode after 20 or 30 minutes, now it may be restarted every half day

I hope my test feedback can help you identify the problem faster

[yoyo930021]

I will study it when free.
You can try #2328 PR. Maybe improve part of the problem.
I think we can provide a VSCode command for restart Vetur LSP.
So no need to restart VSCode everytime.

@yoyo930021 Thank you for your attention to this issue
I read #2328 PR, is this a statistic about nodeModuleSnapshots? I will try to test this statistic

Recently I cloning vetur and did some tests

First of all, I checked the profile I got before, and I saw that the doValidate function was called many times, and it took a long time

In addition to my usual experience, when the vetur is running slowly, if you quickly type in a string of unformatted code that will report an error, the formatting error prompt is obviously delayed from your operation, and the execution of the formatting error prompt is completed. Before, all other operations, such as saving, code hints, would be blocked

So I started with this function, I tried

vetur/server/src/services/vls.ts

Line 495 in 2e32351

doValidate(doc: TextDocument): Diagnostic[] {

In the first line of this function directly return []
Then I tested it locally, and I found that everything became very fast, including the replacement of more than 30 files. Of course, I only tested for a while, because all error verification was turned off, so typing in any code There is no error prompt, but all code prompts are complete and fast

Next, I found that this function calls the doValidation function for specific verification operations. I searched for the doValidation function in the project, and I found that it is roughly composed of 3 parts
script

vetur/server/src/modes/script/javascript.ts

Line 109 in 2e32351

doValidation(doc: TextDocument): Diagnostic[] {

style

vetur/server/src/modes/style/index.ts

Line 59 in 2e32351

doValidation(document) {

template

vetur/server/src/modes/template/index.ts

Line 50 in 2e32351

doValidation(document: TextDocument) {

I tested these three parts separately. In the first line of the function, directly return []
In the tests of script and style, I found that there is no significant effect change
In the test of template, I found that return [] has significantly improved the speed
Then the verification of template is composed of 2 parts

vetur/server/src/modes/template/index.ts

Line 51 in 2e32351

return this.htmlMode.doValidation(document).concat(this.vueInterpolationMode.doValidation(document));

One part is htmlMode, part is vueInterpolationMode
After testing the two parts separately, I found that when the doValidation of vueInterpolationMode is disabled like this

return this.htmlMode.doValidation(document)

Performance has been significantly improved, at least the code prompt will basically not be stuck
Of course, in this way, the above code error prompt of template is gone, but compared with the code prompt, this is still acceptable.

If you directly set vetur.experimental.templateInterpolationService to false, there will be no code hints on template. This kind of experience is meaningless for developing with typescript. Now I have turned off template locally. Error checking, but retains other field prompts and other functions

So if this performance problem cannot be solved temporarily, I hope I can temporarily provide an option to turn off error checking on template @octref
Just like #2150 (comment)

After a period of use, I found that the performance of vetur will still slow down over time, but it is much better than before. When it is slow, the code prompt takes about two or three seconds instead of the previous 20- 30 seconds, but I think this effect is acceptable for the time being, because before I used to restart vscode after 20 or 30 minutes, now it may be restarted every half day

I hope my test feedback can help you identify the problem faster

Hi @Eurkidu , this option is existing. The name is vetur.validation.interpolation.
Another, I don't think this feature meaningless. we can validate script and template type relations.
And you can follow #2332, It solving some of the problems

[Eurkidu]

Hi @Eurkidu , this option is existing. The name is vetur.validation.interpolation.
Another, I don't think this feature meaningless. we can validate script and template type relations.
And you can follow #2332, It solving some of the problems

Thanks, I found this option

Yes, not verifying the code on the template is just a temporary solution

I will test it #2332
I will give feedback if there is news, thank you for your work

[yoyo930021]

The #2328 is reduced recreate ts program.

You can find calling synchronizeHostData function in typescript code.
https://github.com/microsoft/TypeScript/blob/dc4ccc7d41ff9be90a949eb76fa9c0892d5af6d1/src/services/services.ts#L1505
It ensure that ts service having latest code in project.

I analyze synchronizeHostData function with node debugger.
I was pleasantly surprised to find that it always create program.
I'm not sure what we broke something.
https://github.com/microsoft/TypeScript/blob/dc4ccc7d41ff9be90a949eb76fa9c0892d5af6d1/src/services/services.ts#L1278

I finally found getProjectVersion. It can talk to ts service when do we need to recreate program.
It makes doValidate at least twice as fast!

[yoyo930021]

I've found out why it's slow when using typescript template service and borken #2192 (comment).
vetur.experimental.templateInterpolationService: true.

The synchronizeHostData function will check up to date with isProgramUptoDate function.
https://github.com/microsoft/TypeScript/blob/c88e44a9e65f7d7a72ef72c9dfae94ef0fcb6bb0/src/services/services.ts#L1307

It check sourceFileNotUptoDate with using sourceFile version property equal to host.getScriptVersion(sourceFile.fileName) result .
https://github.com/microsoft/TypeScript/blob/c88e44a9e65f7d7a72ef72c9dfae94ef0fcb6bb0/src/compiler/program.ts#L579

When template sourceFile, The sourceFile get version property undefined.
Because we create new sourceFile when generated template code,
and missing version, scriptSnapshot properties in language service sourceFile.

vetur/server/src/services/typescriptService/preprocess.ts

Line 118 in a733125

const newSourceFile = tsModule.createSourceFile(

I fix this problem in #2374.

[Eurkidu]

Hi @yoyo930021 Thank you so much

I tried #2332 and #2328 before
The performance problem is better than at the beginning, but it is still very slow. I closed vetur.validation.interpolation and vetur.languageFatures.codeAction because of work later. After closing these two items, the performance is not so bad

I read your latest reply the day before yesterday. I understand that this problem is probably related to typescript sourceFile version. Then I merged #2328 and #2374 locally and used it for a while, and also opened the previously closed vetur. .validation.interpolation and vetur.languageFatures.codeAction

After 2 days of use, I found that this is really great, everything has become very normal, I don’t need to restart vscode again after I work a day, I think the problem is probably solved, and there is basically no physical feeling the performance drops over time

However, I still have a little confusion. When I perform batch file replacement, even if I only replace a comment globally, in the case of about 28 files, the replacement needs to be executed for about 15s, about 500ms for each file, depending on the status The column prompt is that vscode is formatting each file. Is this effect normal, but after the file batch replacement is completed, it will not slow down the overall operation as before. This is perfect.

I will continue to test my local version, but I think the problem is probably solved. I hope that if there is no problem in the test, #2374 can be merged as soon as possible @octref

[yoyo930021]

Hi @yoyo930021 Thank you so much

I tried #2332 and #2328 before
The performance problem is better than at the beginning, but it is still very slow. I closed vetur.validation.interpolation and vetur.languageFatures.codeAction because of work later. After closing these two items, the performance is not so bad

I read your latest reply the day before yesterday. I understand that this problem is probably related to typescript sourceFile version. Then I merged #2328 and #2374 locally and used it for a while, and also opened the previously closed vetur. .validation.interpolation and vetur.languageFatures.codeAction

After 2 days of use, I found that this is really great, everything has become very normal, I don’t need to restart vscode again after I work a day, I think the problem is probably solved, and there is basically no physical feeling the performance drops over time

However, I still have a little confusion. When I perform batch file replacement, even if I only replace a comment globally, in the case of about 28 files, the replacement needs to be executed for about 15s, about 500ms for each file, depending on the status The column prompt is that vscode is formatting each file. Is this effect normal, but after the file batch replacement is completed, it will not slow down the overall operation as before. This is perfect.

I will continue to test my local version, but I think the problem is probably solved. I hope that if there is no problem in the test, #2374 can be merged as soon as possible @octref

Thanks your test.
I'm glad the problem is solved.

You can open a new issue about format performance problem.
Basically, it involves your format settings and third-party format libs.

Here's a method for determining problem whether it's Vetur or not:

1. Set "vetur.trace.server": "messages" in vscode config.
2. Open a test project about vue.
3. Open output panel and switch to Vue Language Server.
4. Replacing text in project.
5. Find Received response 'textDocument/formatting - (x) in xxxms.
6. The xxxms text is the time it took to format one of the files.

[milidubey]

I encountered the same issue with Vetur on VSCode and macOS bigsur. Vetur would take too long to save a file and I had to click on cancel to save the file. The issue seems to have been resolved on my machine (at least for now).

Here are the steps -

1. Reinstall VSCode (Not sure if everyone needs this)
2. Open your workspace
3. Press CMD + Shift + P
4. "Disable all installed extensions for this workspace"
5. VSCode would then suggest Vetur as a recommended extension, install or enable it.
6. Install / enable other extensions only needed for workspace like prettier etc.