PSES using large amounts of memory (> 1GB)

[darksidemilk]

Issue Description

I've noticed recently that my vscode is often using nearly 2 GB of Ram, which seems a bit high for a text editor, but I figured it was just too many editors open. Today I looked a little deeper and found that it's mostly from one attached powershell process.

The command line of the process looks like this

powershell.exe -NoProfile -NonInteractive -ExecutionPolicy Bypass -Command "& 'C:\Users\jfullmer\.vscode\extensions\ms-vscode.powershell-1.8.5-insiders-344\modules\PowerShellEditorServices\Start-EditorServices.ps1' -HostName 'Visual Studio Code Host' -HostProfileId 'Microsoft.VSCode' -HostVersion '1.8.5'-AdditionalModules @('PowerShellEditorServices.VSCode') -BundledModulesPath 'C:\Users\jfullmer\.vscode\extensions\ms-vscode.powershell-1.8.5-insiders-344\modules'-EnableConsoleRepl -LogLevel 'Normal' -LogPath 'C:\Users\jfullmer\.vscode\extensions\ms-vscode.powershell-1.8.5-insiders-344\logs\1538142585-1cf6b591-dd5a-464d-9e6a-a74f0bfc0de21538142567631\EditorServices.log' -SessionDetailsPath 'C:\Users\jfullmer\.vscode\extensions\ms-vscode.powershell-1.8.5-insiders-344\sessions\PSES-VSCode-27000-874907' -FeatureFlags @()"

This script seems to start when I open vscode and doesn't seem to close. There is various hanging on powershell extension functions while I'm editing. From parameter/function auto complete to help comment block creation.
I'm thinking there may be something causing it to hang or use more RAM then expected.

Environment Information

Visual Studio Code

Name	Version
Operating System	Windows_NT x64 10.0.17134
VSCode	1.27.2
PowerShell Extension Version	1.8.5-insiders-344

PowerShell Information

Name	Value
PSVersion	5.1.17134.228
PSEdition	Desktop
PSCompatibleVersions	1.0 2.0 3.0 4.0 5.0 5.1.17134.228
BuildVersion	10.0.17134.228
CLRVersion	4.0.30319.42000
WSManStackVersion	3.0
PSRemotingProtocolVersion	2.3
SerializationVersion	1.1.0.1

Visual Studio Code Extensions

Visual Studio Code Extensions(Click to Expand)

Extension	Author	Version
autoit	Damien	0.2.0
confluence-markup	denco	0.1.3
cpptools	ms-vscode	0.18.1
git-extension-pack	donjayamanne	0.1.3
git-project-manager	felipecaputo	1.7.1
githistory	donjayamanne	0.4.2
gitignore	codezombiech	0.5.0
gitlens	eamodio	8.5.6
markdown-all-in-one	yzhang	1.6.0
markdown-mermaid	bierner	1.0.0
PowerShell	ms-vscode	1.8.5-insiders-344
project-manager	alefragnani	9.0.1
systemd-unit-file	coolbear	1.0.0
Theme-Eiffel	gerane	0.0.2
vscjira	TheOneSock	0.0.2
vscode-autohotkey	slevesque	0.2.2
vscode-jira	KnisterPeter	0.6.0
vscode-markdownlint	DavidAnson	0.20.0
vscode-open-in-github	ziyasal	1.3.5
vscode-sequence-diagrams	AleksandarDev	0.3.1
xml	DotJoshJohnson	2.3.2

[rjmholt]

Possibly related to #1464.

If you are able to diagnose or profile this in any more detail we are grateful for any data you can provide. VSCode/Electron already loves machine resources, but I'd like to drive our footprint down as much as possible. One thing we've learned is that every machine profile is different and trying to reproduce a performance issue between machines is a challenge.

The PowerShell process you're looking at is PowerShell Editor Services, which is what does all the heavy lifting for the extension. So it makes sense that it has a relatively large footprint (for example, it generates a new PowerShell AST every time you press a key), but I am currently working on reducing that as much as possible.

[darksidemilk]

Thanks for the reply. That issue might be related, however my cpu usage isn't an issue. And playing around with it on a different computer it does gradually increase in size but on the one I reported from there is unresponsiveness more often.
I'm going to try some of the suggestions in the related issue. However disabling scriptanalyzer isn't ideal because I really like that feature.

[rjmholt]

Yes disabling features isn't a long term solution.

We have been working on performance in general. The CPU/memory usage is related since memory/resource-intensive operations increase garbage collection pressure. In the coming release I'm hoping you'll experience some improvements in both.

Another thing to bear in mind is that memory allocated to an application is not necessarily in use. The OS will try to allocate based on need, and it's really memory pressure/thrashing that is a worry.

But as I say, if you can provide any more information on what inside that PowerShell process is asking for all that memory, like with a usage or profile trace, that would be very helpful.

[darksidemilk]

I disabled scriptanalyzer and things sped up significantly. So that perhaps narrows it down a bit. Maybe I just have too many errors in my code...I hope not, I really don't have that many.
How would one do a trace on this process to narrow it down further? Or would it be better to play with the psscriptanalyzer options and see if there's a specific type of error that uses more resources to scan for?

[rjmholt]

Ah, yeah ScriptAnalyzer is pretty much next on the list of things for us to work on. It's a bit of a resource hog unfortunately and we're trying to find ways to isolate it, but ultimately we depend on work being done in PSScriptAnalyzer itself (in https://github.com/PowerShell/PSScriptAnalyzer).

So theoretically the best way to get trace/profile data is with Visual Studio or Windows Performance Toolkit. But unless you've used them before or something similar, they're fairly unintuitive.

Instead, it's probably worth:

• Seeing what improves when you disable ScriptAnalysis and CodeLenses
• Seeing if enabling/disabling particular PSSA rules affects anything
• Being mindful of what you're in the middle of when you experience a performance degradation and reporting it (ideally with logs)

Sorry that's not more helpful. Ideally we'd have a simple profiling tool to plug & play with, but I don't think we're really close to that yet. WPT does do a plug/play dump though, so if you want to try using that, you can just send us the dump and we can analyse it

[darksidemilk]

I am familiar with the other tools in the windows ADK so I'll see what I can do with the windows performance toolkit.
I'll keep the rest of that in mind as well.
Perhaps I could also do a workaround of using the psscriptanalyzer externally and on demand.

[JeremyTBradshaw]

One thing I'm trying (and yes I see this is 5+ years later) is this:

CTRL+SHIFT+P (command palette opens)
PowerShell: Restart Session (restarts just the PowerShell Extension pwsh.exe (that's for me, using PowerShell x64 as the default)).

What's kind of cool is you can click the gear wheel beside "PowerShell: Restart Session" and give it a key binding. I went with CTRL+ALT+P. To test, I first to the command" PowerShell: Show Extension Terminal" so I can actually see it in the panel, then I do my CTRL+ALT+P to see it disappear again (since I check that box to start it in the background, which is a default I believe).

I have found on my 16GB RAM laptop, with present day current version VSCode, the pwsh.exe (which the Command Line in Task Manager shows as the one with Import-Module ...PowerShellEditorServices.psd1) will have consumed 10+GB of RAM. This is while I use 3 other pwsh.exe instances in the same VSCode panel, each connected to a different Exchange environment (EXO, 2x on-premises). Those pwsh.exe's don't have the high memory consumption typically, but the extension's pwsh.exe definitely does. It's fine though now that I know how to recycle it per se.

[andyleejordan]

@JeremyTBradshaw when we saw reports of high memory usage it's almost universally caused by having a workspace with many PowerShell files, as this by default causes the extension to run PSScriptAnalyzer and symbol finding on all the files. To alleviate this issue we added the setting powershell.analyzeOpenDocumentsOnly when when set to true will restrict symbol finding and other analysis just to the files you've opened (instead of scanning the whole workspace). Please try that out!

[JeremyTBradshaw]

Thanks for that, very much! Makes perfect sense. I was searching around for existing issues but hadn't come across that yet. Will give it a go, leaving the restart trick as last resort.

[github-actions]

This issue has been labeled as resolved and has not had any activity for one or more days. It has been closed for housekeeping purposes.