PSES frequently gets stuck in a loop and never recovers #1342
Comments
rjmholt
added
Issue-Bug
|
Aha! Thanks so much for this report. There's a general awareness of this and we've been looking at improving the performance of PSES, but I think the logs you've attached here could be really helpful. /cc @tylerl0706 |
|
I started getting this problem after the most recent VS Code update. It occurs when trying to auto format the document or use code completion. The status bar will show the message "Formatting PowerShell document" for over a minute, without any formatting or code completion happening. This is what I have: Here is a relevant snippet from the log when this happens:
|
|
Never mind, after turning on verbose logging I can see the problem is the new PS script analyser that has recently been updated in the PSES version that comes with this extension causing the delay. The scripts I was looking at are large, ~2000 lines and it seems the script analysis is taking around 45 seconds to do its thing. It runs on every formatting or code completion request, causing the hangs. I see a lot of changes have happened to the code analysis in the recent release of PSES. I don't need script analysis so I've disabled it and now I'm back to previous performance levels. |
|
@Falconne we believe we've addressed the top issue, but without a known cause it's hard to be sure. Making script analysis less impactful on the rest of the experience is something that we've been working away at in the background, but requires some architectural work. |
|
@rjmholt I'll try script analysis again periodically to see how it goes. It would help if that ran in a background thread instead of blocking document formatting and code completion... which don't seem to need it anyway? |
|
Yes, script analysis already runs asynchronously as a task. (Threading not being chosen because it didn't originally exist cross-platform). The problem seems to be more that message handling itself is not as asynchronous as it could be, meaning messages still block and cannot be interrupted. But fixing that properly is a large architectural change, which we need to be careful with since PowerShell itself doesn't really handle threading so well. |
|
At least for me, the problem does not appear to be related to script analysis. Disabling it in the VS Code options does not have a meaningful impact, and I haven't observed any changes in newer versions of the extension since I filed this issue. Since the PSES process is generally pegged when this issue is occurring, I thought attaching a profiler might suggest something. A cursory look suggests almost all the time is being spent (re-)parsing PowerShell files (on disk) to service CodeLens requests. See below (the collapsed threads are Serilog waiting for stuff to log and ReadKey waiting for keystrokes):
So, I tried turning off CodeLens in VS Code. This is unfortunate because I find it super useful, but it does seem to have had the desired effect. IntelliSense keeps working and I don't have a powershell process burning a core at all times. This is very speculative, but I'm guessing that because I'm typically working with large files (4 digit loc) and workspaces (6 digit loc) re-parsing things is very expensive and it's easy to build up a backlog where everything seems to stop working. That would naturally lead to a question of whether the any of these parsing results could be cached in a way that would allow PSES to "keep up". Or maybe I have no idea what I'm talking about, I'm not very familiar with the extension or PSES code bases. |
|
I probably spoke too soon. Disabling CodeLens definitely helped, but the extension still has a lot of trouble keeping up. It seems like operations often have trouble finishing within what appears to be a timeout from VS Code for things like IntelliSense completion. Will try to dig further if that's helpful... |
|
@mattpwhite thanks for that really great analysis! Definitely agreed we need to cache codelens as much as possible (see PowerShell/PowerShellEditorServices#678). VSCode controls sending CodeLens messages, so we have no choice but to improve the way we deal with them. I think step 1 is to improve caching, and step 2 will probably be a way of cancelling/rejecting code lens messages. If you find any other useful information, please keep us updated! |
|
If I saw some low hanging fruit (and I do), would it be OK to send over a PR or two to improve perf? |
|
@mattpwhite absolutely! PRs always welcome 😊 Sorry we haven't been looking into this at the moment. We've been pulled to work on porting Windows PowerShell modules and in my free time, I'm working to get PSReadLine into the extension (with @SeeminglyScience). After PSReadLine is in, perf is my number one goal. I appreciate any extra hands 😊 |
|
+1 on what @tylerl0706 said |
|
As far as I know, the original looping behaviour described in this issue has been fixed. I'm going to close it, but if it turns out I'm wrong, please feel free to reopen. Also note that we are tracking performance problems in several other open issues currently. |
System Details
Win10 1703
With great frequency, communication between the VS Code extension and PSES seems to get "stuck". Basically all extension functionality (formatting, IntelliSense, F12) ceases to work and I get the same series of log messages repeated every ~10 seconds. The log messages repeat even when no changes are being made. All I can do is restart the session and hope for the best. Restarting is hit or miss in terms of recovering.
I wish I was able to repro this reliably, but I can't. It more likely to happen with large files (several thousand lines of code or more). It also seems more likely to occur with large workspaces (hundreds of files, hundreds of thousands of lines of mixed PS and C# across ~100 modules). I get that these numbers may be on the high side, but I know that it can work. After a fairly lengthy initialization period it often works/performs reasonably for some period of time, and then breaks.
Here's a sample of what I get repeating in the logs:
The text was updated successfully, but these errors were encountered: