Vscode-powershell: Constant CPU load

[ya-alexander]

Issue Type: Performance Issue

Hi,

whenever I run a PS script in VS Code, the CPU load keeps staying at around 15-20% although the execution of the script already finished. It seems that Windows PowerShell is causing the actual load. Do you have any tips to remedy that behavior?

Thanks,
Alex

Extension version: 1.8.2
VS Code version: Code 1.25.1 (1dfc5e557209371715f655691b1235b6b26a06be, 2018-07-11T15:43:53.668Z)
OS version: Windows_NT x64 10.0.17134

System Info

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (8 x 1992)|
|GPU Status|2d_canvas: enabled
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
native_gpu_memory_buffers: disabled_software
rasterization: disabled_software
video_decode: enabled
video_encode: enabled
vpx_decode: enabled
webgl: enabled
webgl2: enabled|
|Memory (System)|31.86GB (24.18GB free)|
|Process Argv|C:\Program Files\Microsoft VS Code\Code.exe|
|Screen Reader|no|
|VM|0%|

[rkeithhill]

What happens if you disable script analysis with the setting "powershell.scriptAnalysis.enable": false?

[ya-alexander]

Thanks for your quick reply. Unfortunately, disabling script analysis does not help. CPU load is still high although the script has finished running.

[rjmholt]

@ya-alexander This issue may have some more information: https://github.com/PowerShell/vscode-powershell/issues/1174#issuecomment-379232062. Does disabling CodeLens help?

[ya-alexander]

@rjmholt Thanks a lot. I tried disabling CodeLens and, at least for now, can confirm that it helped a bit. Windows PowerShell is still using 6-8% of CPU, but that is way less than the > 15% before. Do you have any more tips like that :-)

[RussPitcher]

I've been having a similar issue when working on a 3000-line script with one hyper-threaded core from my 2-core laptop regularly nailed at 100% on a PowerShell process under VSCore and very laggy performance. I also noticed that the status bar almost constantly had 'Formatting PowerShell document...' running.

Disabling CodeLens helped, but not a great deal. Disabling script analysis has made a massive difference.

[rjmholt]

Yeah disabling ScriptAnalysis is the other tip.

It looks like different features are performance bottlenecks on different machines.

If anyone is hitting an issue like this, try disabling individual features (should be similar to how CodeLens is disabled) and report back here -- it's much easier for us to determine the cause of performance issues with information like that on hand.

[dpaulson45]

I think i might be seeing the same issue. I just filed #1503 for PowerShell using a large amount of CPU. Let me know if i can do anything to assist with debug/repro.

[rjmholt]

@dpaulson45 Can you try disabling script analysis and tell us what you find? Then re-enable it and try disabling CodeLens. Then disable both. And report back on what effect each has? Thanks!

[dpaulson45]

@rjmholt after disabling script analysis the CPU issue doesn't occur after i reload Visual Studio Code. CodeLens doesn't appear to matter if this is enabled or disabled.

[DarkLite1]

Related issue here, very high memory consumption (4GB) when running VS Code Insiders (latest). The only thing I use it for is developing PowerShell scripts. When checking the Task manager I noticed that it's the process Windows PowerShell that consumes this memory. Closing VS Code instantly releases the memory.

The weird thing is, I'm not even running code when the memory is high. The PowerShell terminal in VS Code is just sitting there doing nothing while the memory is still being consumed by PowerShell as appears in the Task Manager.

[BKFlister]

Related issue,
pwsh uses 90-110% cpu.
Disable "Script.Analysis" and the CPU usage is normal.
MacOs 10.13.5, VS Code 1.29.1, Powershell Extension 1.9.0, Powershell Core 6.2.0preview2.

[MattLParker]

My #1648 was closed and referenced here, however it seems that my issue is completely unrelated to this.

[MattLParker]

Since my other was closed, I'll comment here. It appears that when using import-pssession with a -prefix
it seems to continually hang due to the large number of new commands that it is importing.
in my test I am doing a single function that connects to two seperate exchange enviroments, both with a custom prefix. So for example I will have a get-01mailbox and get-02mailbox. It seems that it will continually try importing, then failing and repeating the process.

[Hypernut]

Same thing here. Fresh start of VScode, the "integrated console" is immediately using 25% CPU. ProcessEpxlorer shows that it is constantly opening and closing threads. Memory usage is increasing slowly but constanly.

[bferg317]

Same issue. 8th gen i7, 35-40% CPU load for several minutes when I start vscode or switch .ps1 files. Disabling CodeLens had no noticeable effect whatsoever; but my projects are very compartmentalized and it seems the effect scales with reference complexity.
Disabling ScriptAnalyzer dropped CPU usage to ~20%.

Also worth noting, my terminal does not render until I start typing.

[rkeithhill]

Please update to PSScriptAnalyzer 1.18.0 and see if the problem persists.

Install-Module PSScriptAnalyzer -Scope CurrentUser -Force

You need to restart VSCode (or at least the PowerShell session) after executing this command.

[Hypernut]

Yep that fixed it for me.
Oddly get-module -listavailable shows the new version in WindowsPowerShell\Modules, but still the old version 1.17 in .vscode\extensions\ms-vscode.powershell-1.11.0\modules

[DarkLite1]

@Hypernut same experience here: Get-Module -ListAvailable shows version 1.17.1 and in the PowerShell module folder there is only the new one, version 1.18.0.

It's in two different folders, that's probably why.

[Hypernut]

I think the one in the extension-folder only gets updated when the powershell extension as a whole gets updated. But that would also mean the powershell console in vscode uses a different module than the editor in vscode?

[bferg317]

Running the command @rkeithhill (edit: I referenced wrong user) gave made no change--in fact, the test was significantly worse, but I think there's just an extreme amount of variability in behavior here. Yes, I restarted vscode after running it.

[Hypernut]

@cmcit-bferg
I dont know why, but it took some time before it calmed down. :)
Check if you have the latest version installed with get-module -ListAvailable -name PSScriptAnalyzer

[bferg317]

@Hypernut Like the others, I have 1.18.0 in my path, but 1.17.1 in home\.vscode\extensions...

[rkeithhill]

I think the one in the extension-folder only gets updated when the powershell extension as a whole gets updated.

Correct

But that would also mean the powershell console in vscode uses a different module than the editor in vscode?

They both should be the same - 1.18. The one that the editor uses is loaded into runspace 4 which you cans see by running this (Get-Runspace 4).CreatePipeline("gmo", 0).Invoke() from the PSIC.

[rkeithhill]

The basic idea is that the extension will use the latest version you have installed but it does provide a version in case you don't have any version installed.

[bferg317]

After update, CPU usage spikes a little higher than before but for a much shorter period of time. VSC is now using PSScriptAnalyzer 1.18.0

[rjmholt]

To address questions about where and how PSScriptAnalyzer is loaded:

• The Integrated Console is the same PowerShell process running in-editor script analysis. It's also possible to run powershell or pwsh in the VSCode console, which doesn't speak to the extension at all. You can check which you're in, look for the $psEditor variable.
• The PowerShell extension takes the environment PSModulePath and adds the extension's own modules folder to the end of it, so the modules it ships are available but don't take precedence.
• Currently, the PSScriptAnalyzer the extension loads is the highest available on the module path, so that if there's a PSSA release with bug fixes, you can try that out without any code changes in the extension. (We want to change this to lock to the minor version, so that a new version doesn't break an old extension version)
• This means the PSScriptAnalyzer you get in the Integrated Console will be the first on the module path, but the one running in-editor analysis will be the highest version on the module path. Most of the time these will be the same.

[rkeithhill]

And to check which version of PSScriptAnalyer got loaded for in-editor analysis, run this command: (Get-Runspace 4).CreatePipeline("gmo", 0).Invoke()

[SydneyhSmith]

Going to close this as a result of the major architectural changes we made in the omnisharp port.