Closed LittleSound closed 2 years ago
I can confirm this on my system as well. It's quite ridiculous waiting for insights take +5-10s and makes it impossible to get insights with any sort of speed.
"javascript.suggest.autoImports": false
and "typescript.suggest.autoImports": false
in VSCode?
- (If this is a recent issue) Which version did this issue start appearing?
- Do you have update typescript version? And what's is your typescript version? (See status bar when opened .vue file)
- Can this problem alleviate by setting
"javascript.suggest.autoImports": false
and"typescript.suggest.autoImports": false
in VSCode?
Okay, I'll try to change these settings to test when I get back to work next week; I suspect the lag may be related to some of the node
processes not being closed properly, which may take some time to occur with use, so it's not immediately reproducible.
(If this is a recent issue) Which version did this issue start appearing?
Do you have update typescript version? And what's is your typescript version? (See status bar when opened .vue file)
Can this problem alleviate by setting
"javascript.suggest.autoImports": false
and"typescript.suggest.autoImports": false
in VSCode?
If I had to pinpoint a release it would probably be the last 3, notably the worst being 0.39.0
Doing what you suggested plus the update you released yesterday and today seemed to have make it a bit quicker as well. As for my TS version I am running 4.7.3
So it seems when importing items it goes by each char rather than waiting for a word or something to appear. There's no delay. This could def cause issues with the performance.
@brys0 Maybe you're looking for volar.diagnostics.delay
setting.
Please let me know if this version can alleviate the problem or not: volar-0.39.2-alpha.1.vsix.zip
There appears to be no difference. Apologies for the wait.
It's too slow to use
I've removed every extension did a fresh install of vscode and just installed Volar and it's still just as slow. I have no idea what might be happening, based on what you said it could be related to certain node modules? Such as @vicons
libraries causing Volar to scan the entire module which has upwards of 300+ vue files. Any advice for other people is I would consider somehow removing intelisense on large node modules like naive-ui and any icon library that directly uses .vue
files.
@brys0 Could you provide profiling record? (See #413)
Yes. For debugging it used around 1.5gb of memory for the project (Is that alot?). Below is a zip of the entire cpu profile as well as a screenshot CPU-20220725T003725.zip
For debugging it used around 1.5gb of memory for the project
It depends on tsconfig count and node_modules size, if volar.vueserver.useSecondServer
is enabled also uses more memory.
Please try volar-0.39.2-alpha.2.vsix.zip, which try to cache statSync(fileExists, directoryExists) result.
Please try volar-0.39.2-alpha.2.vsix.zip, which try to cache statSync(fileExists, directoryExists) result.
@johnsoncodehk I just tried this version, which is much better than before, but there is still a little delay. Thank you for doing this.
delete lang="ts" and prompt quickly
delete lang="ts" and prompt quickly
Version 0.39.2 is a little faster after setting lang="ts", but it can't do the same second prompt as if lang="ts" is not set
再现个鬼, 你开个2000行左右的vue文件,插件提示直接歇菜,慢得一批~!换回vuter后,一切正常~!
再现个鬼, 你开个2000行左右的vue文件,插件提示直接歇菜,慢得一批~!换回vuter后,一切正常~!
Okay, this looks like your first issue, how about to take a look at what others are doing? I think we all know disabling extension to avoid it couldn't help anything, so why not do something more meaningful, like try and see if something like this happens to you? :)
@brys0 Please let me know if this version have difference or not: volar-0.39.5-alpha.1.vsix.zip
I found that latest VSCode built-in TS v4.7.3 has performance issue with defineComponent
, please also try install typescript v4.6.4 in workspace, and change VSCode tsdk to workspace TS version.
I figured it may have been an issue with typescript trying to work with 2 different versions. Lovely you found the issue, thanks for taking your personal time to fix it. Much love 🤍
I can also confirm this. It suddenly got slow. I uninstalled VsCode and it's settings, cleaned cached, did general cleaning but still slow.
@brys0 Please let me know if this version have difference or not: volar-0.39.5-alpha.1.vsix.zip
Tried this one but it is the same. Thanks for your time though. Hope this gets solved.
For now I downgraded to v0.38.5
and syntax highlighting got much faster just like before.
@onurusluca Thank for the information, is this problem begin in v0.38.6?
v0.38.5 ~ v0.38.6 only have one commit and it should be unrelated, so I'm out of ideas for now.
I still can't reproduce this performance issue, I may need someone try with each commit after v0.38.5 and let me know which commit cause the problem.
@johnsoncodehk Thanks a lot for the reply. Sorry for not specifying the problem. I chose v0.38.5 because the next update from that has a longer gap.
I am testing all the versions now. It is taking a bit of a time. I will write here as soon as I am done testing.
Also great job with the extension. I love Volar!
@johnsoncodehk Got it!
The problem starts from v0.39.2
.
Previous versions take 1 second or less to highlight a syntax problem but v0.39.2 and later takes 3 seconds or more.
I am more than happy to provide any details you need, just ask.
For now I am providing the default details:
VsCode: June 2022 (version 1.69)
Operating System: Microsoft Windows 10 Home 64-bit CPU: Intel(R) Core(TM) i7-10875H CPU @ 2.30GHz Motherboard: Alienware Alienware m17 R3 (U3E1) RAM: 32.00 GB Unknown form factor Unknown 2667MHz GPU: Intel(R) UHD Graphics 1024 MB NVIDIA GeForce RTX 2070 Super 4095 MB
System: OS: Windows 10 10.0.19044 CPU: (16) x64 Intel(R) Core(TM) i7-10875H CPU @ 2.30GHz Memory: 18.41 GB / 31.77 GB Binaries: Node: 18.7.0 - C:\Program Files\nodejs\node.EXE npm: 8.10.0 - C:\Program Files\nodejs\npm.CMD Browsers: Edge: Spartan (44.19041.1266.0), Chromium (103.0.1264.77) Internet Explorer: 11.0.19041.1566
@onurusluca Thanks to confirm this, v0.39.2 is later than this issue, it should be a different problem, could you open a new issue for this?
@johnsoncodehk Hey. What do you mean by 'latter than this'? Alright, let me open one.
Created a new issue on this: https://github.com/johnsoncodehk/volar/issues/1663
@onurusluca Sorry just typo, I mean v0.39.2 released later than this issue open.
same problem.
CPUs | AMD Ryzen 7 PRO 2700 Eight-Core Processor (16 x 3194) -- | -- GPU Status | 2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled Load (avg) | Memory (System) | 31.91GB (22.40GB free) Process Argv | --crash-reporter-id 25c7f289-8e5d-4614-90ff-f88a062f3d82 Screen Reader | no VM | 0%volar 0.39.4
Since a while, I am also having memory issues and finally I am quite sure it is coming from volar. Only difference is, I am not running volar in VS Code but in Neovim. Maybe that helps pinpoint it down. Neovim and volar are running in two separate processes, but still the nvim process is hogging more and more memory
In this example it took 6.8GB of RAM. It can't be Neovim itself, because opening and using a Rust project for longer with its lsp, the memory stays constant and low, same with a pure js/ts project with eslint-lsp.
For me it is no instant lag or problem. The memory keeps growing and growing during the usage. Also, when I pause for a long time neither stop the application, the memory doesn't go down or increase but stays at one level. If I continue using it, the memory usage continues to go up. Seems like a memory leak to me?
Why the memory accumulates in the nvim process could be that the Neovim LSP is caching too much stuff from the volar lsp, as suggested by @Mehalter in AstroNvim/AstroNvim#797.
Hope this is helpful!
My Vs Code volar process keep increasing in ram usage then it`s restart and start again from the beginning My Ts version : 4.7.4 My volar version : v0.40.1
Since a while, I am also having memory issues and finally I am quite sure it is coming from volar. Only difference is, I am not running volar in VS Code but in Neovim. Maybe that helps pinpoint it down. Neovim and volar are running in two separate processes, but still the nvim process is hogging more and more memory
In this example it took 6.8GB of RAM. It can't be Neovim itself, because opening and using a Rust project for longer with its lsp, the memory stays constant and low, same with a pure js/ts project with eslint-lsp.
For me it is no instant lag or problem. The memory keeps growing and growing during the usage. Also, when I pause for a long time neither stop the application, the memory doesn't go down or increase but stays at one level. If I continue using it, the memory usage continues to go up. Seems like a memory leak to me?
Why the memory accumulates in the nvim process could be that the Neovim LSP is caching too much stuff from the volar lsp, as suggested by @mehalter in AstroNvim/AstroNvim#797.
Hope this is helpful!
For me it is resolves somehow. I just worked for a few hours on a vue project and no performance decrease, neither high memory usage.
Had the same issue. I confirm that, disabling Auto Import Component
showed significant performance improvement.
TS: 4.8.2 Volar: 0.40.1
Please open a new issue for memory usage. I have no reproduction that reproduces the problem so can't check it, I'd appreciate if someone provide a reproduction.
I made some performance optimizations in v0.40.2, please try the new version works for you or not.
@Noxdor I try mitigate memory leak by https://github.com/johnsoncodehk/volar/commit/7337d1c1fef9f51c70387e9352e7e4914800ea2d, please try v0.40.3.
@Noxdor I try mitigate memory leak by https://github.com/johnsoncodehk/volar/commit/7337d1c1fef9f51c70387e9352e7e4914800ea2d, please try v0.40.3.
Thanks for the reply! As I wrote above, for me the issue was already resolved and I am right now on 0.40.1. So it can't have been the changes in 0.40.3. Unfortunately I can't pinpoint it any more precisely.
I am using the latest version 0.40.4,but it also slowly and cost lots of memory
For peoples who still has performance issue with latest version, you can try:
javascript.suggest.autoImports
and typescript.suggest.autoImports
in workspace settings.volar.vueserver.useSecondServer
in workspace settings for better performance, or disable it for less memory usage.Close this issue because do not have anymore helpful information, if you can confirm the performance from plugin, please open a new issue with append repro case or profiling record.
Removing
"editor.codeActionsOnSave": ["source.organizeImports"]
from my global settings, did the trick. Hope it helps.
It is disappointing that this issue was closed as, being the only development tooling for VSCode, the continued performance issues of Volar effectively make VSCode + Vue an incompatible pairing.
(The setting fixes recommended above also do not exist on recent versions of Volar.)
The current version of Volar does not have much overhead, but its performance is limited by TypeScript. If your project itself is a huge TypeScript project, TypeScript LanguageService will analyze it slowly anyway. If you can provide a repro case, I might be able to help find out the performance hotspots in your project. It may come from a certain dependency, or some recursive type. At least the performance problems I have checked recently are all from the project itself.
If you need help please provide a repro case and open a new issue, I'll find time to check it, otherwise I can't help, I'm not a magician.
WebStorm now also uses Volar and it takes almost 9 seconds for the error to disappear. Deleting node_modules and package-lock.json didn't fixed the issue.
https://github.com/vuejs/language-tools/assets/6358971/e8bb548b-2cc5-44f5-b3bd-37792adfc794
What helps is switching Volar with the TypeScript Service. I could try to create some repository where you could reproduce it, but I don't want to share it publicly here. Also I can't guarantee it will reproduce in VSCode.
You may open a new issue, and then provide some logs. Commenting here won't solve this issue...
I had a similar issue: very slow snippet suggestions. Setting "vue.server.hybridMode": true
in settings resolved my issue.
For peoples who still has performance issue with latest version, you can try:
- Disable
javascript.suggest.autoImports
andtypescript.suggest.autoImports
in workspace settings.- Try enable
volar.vueserver.useSecondServer
in workspace settings for better performance, or disable it for less memory usage.- Delete node_modules and check did problems gone or not. If yes, delete package.json dependencies / devDependencies one by one to see which package lead to problems. (If this is the reason, the package usually has lot of .d.ts files.)
- Try Takeover mode.
- (Advanced) Investigate (Performance Tracing)[https://github.com/microsoft/TypeScript-wiki/blob/main/Performance-Tracing.md] use vue-tsc.
Close this issue because do not have anymore helpful information, if you can confirm the performance from plugin, please open a new issue with append repro case or profiling record.
How can I set these settings in a neovim/nvim-lspconfig?
Here is my Nvim config
Issue Type: Bug
This issue is a recent one, perhaps related to the recent update?
Extension version: 0.38.9 VS Code version: Code 1.69.1 (b06ae3b2d2dbfe28bca3134cc6be65935cdfea6a, 2022-07-12T08:22:10.822Z) OS version: Darwin arm64 21.5.0 Restricted Mode: No
System Info
|Item|Value| |---|---| |CPUs|Apple M1 Pro (10 x 24)| |GPU Status|2d_canvas: enabledcanvas_oop_rasterization: disabled_off
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
metal: disabled_off
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_renderer: enabled_on
video_decode: enabled
video_encode: enabled
webgl: enabled
webgl2: enabled| |Load (avg)|8, 10, 10| |Memory (System)|16.00GB (0.09GB free)| |Process Argv|--crash-reporter-id 2999e9bf-ef35-4154-bed3-74f44259cdaf| |Screen Reader|yes| |VM|0%|
A/B Experiments
``` vsliv368:30146709 vsreu685:30147344 python383:30185418 vspor879:30202332 vspor708:30202333 vspor363:30204092 vstes627:30244334 vslsvsres303:30308271 pythonvspyl392:30443607 vserr242cf:30382550 pythontb:30283811 vsjup518:30340749 pythonvspyt551cf:30345471 pythonptprofiler:30281270 vsdfh931cf:30280410 vshan820:30294714 vstes263:30335439 vscoreces:30445986 pythondataviewer:30285071 vscod805cf:30301675 binariesv615:30325510 bridge0708:30335490 bridge0723:30353136 vsaa593cf:30376535 vsc1dst:30438360 pythonvs932:30410667 wslgetstarted:30449410 vscscmwlcmt:30465135 cppdebug:30492333 pylanb8912:30529769 vsclangdf:30486550 841h4636:30531698 ```