Slow performance on Windows

[lukewatts]

I've tried this extension on 3 different projects, across 2 different PCs and on each one the performance is terrible.
It also blocks me from saving a file when it's running analysis on that file.

A colleague has also tried it on their PC at work and found the same.

Running phpstan from the commandline works perfectly. And other extensions in the marketplace don't have these issues

[SanderRonde]

When you say the performance is terrible do you mean that it's slow to do the first check, slow to do re-checks, does too many re-checks, or what exactly?

It also blocks me from saving a file when it's running analysis on that file.

Not really sure why that's happening to you, that's not something the extension does (or even something a VSCode extension can do). It sounds like your PC is just getting overwhelmed by PHPStan running and is unable to save because of this.

But then I'd expect a CLI-invocation to have the same performance impact. Do you run PHPStan in parallel mode at all? Does it saturate your PC as well when ran from the CLI without cache?

[lukewatts]

The initial indexing is slow, but then each time I save, the file doesn't save straight away, the status bar has the "PHPStan checking...." loading state, and after that's done, the file saves.

It's taking 7 - 15 seconds to save a small file

My personal PC (Windows 10) has 16GB ram, i7 processor, and doesn't have issues once I switched to the swordev extension instead.

My work laptop is also i7 and 16GB ram and is running Windows 11. Like I said, a colleague also found the extension to cause performance issues.

Unless it's a combination of this extension and another...?

[SanderRonde]

Hmm that's really weird. The checking is simply an async listener that forwards the request to a language server (meaning it's running in a separate process), which then does the checking. There should be no blocking behavior, and as far as I know VSCode doesn't support it.

What I'm thinking now is:

• VSCode has secretly added a feature where it awaits all async handlers of the on-save hook.
• This is a different extension conflicting and somehow waiting until the PHPStan extension is done (perhaps some other on-save formatting hook?).
• This is some wacky Windows-only issue. While I have tested this on a Windows PC quite often (it's my daily driver) I'm currently at work so not in reach of one. Will test this myself later today.

If you could try and debug option 2 for me (just disable all other extensions and see if it still happens) I'll look into the other 2 later today and hopefully come up with a fix.

[SanderRonde]

Alright I looked into it some more. The promise is discarded so it's not possible that VSCode or the extension is waiting for checking to be done before saving. That means that either:

• Some other extension is doing it (although not sure how they would)
• The system is overloaded to the point where saving fails. Although that would also be strange since the act of saving triggers a check, which means that by definition the file was already saved by the time the check started. It even uses the on-disk saved version of the file.

I did also check it on windows in general and didn't run into any issues. Is there anything particular about your setup given that your coworker has it too? Is it a large project or small etc.

[lukewatts]

Sorry for the delay getting back to you. So I spoke to my colleague to confirm we had the exact same issues and we do.

We hit save, the little dot in the tab remains to show it hasn't saved. The checking loading spinner for PHPStan is in the status bar for 5 to 10 seconds (more for large files), then once the analysis is done the file saves (the unsaved dot in the file tab goes away)

This happens on both of our laptops, but also my personal PC, so the only extension I can think of that would be on all 3 is IntelliPhense, which does its own checking on save...

As for project type and size, 2 of the projects are custom PHP 8.3 projects, ans one is a Laravel project. My personal project is very small and very few dependencies.

Hope this helps. I might not have time to try your suggested fixes until after the holidays

Thanks for looking into this!

[SanderRonde]

Hmm it taking longer for larger files is interesting. What settings are you using for the extension? Are you using singleFileMode?

And indeed I don't think intelephense is the issue, I use that regularly myself too.

[lukewatts]

I tried singleFileMode to see if that helped, but it didn't help for me. Not sure about my colleague. They uninstalled the extension pretty quickly to be honest, so I doubt they took the time to do any tweaking

[SanderRonde]

Alright so if I summarise this there's two issues (right?):

• Performance is worse than other extensions and than the command line. Meaning it takes up more CPU or taxes the computer more when doing a scan from the extension than running it from the command line would?
• The file doesn't appear to save until the on-save scheduled check is done.

Are both of these the case even for your small project? And does the PHPStan check that runs find issues that are caused by saving the file? If so, that means the file was actually saved on-disk but somehow the UI just doesn't reflect it.

I'll also try and add a sort of collect-debug-information mode to the extension to hopefully debug the first issue some more.

I know these are a lot of questions but I've never gotten a report of this before (let alone 2 people having the problem) and of course I want to fix any issues in the extension that warrant somebody giving a 1-star review.

[lukewatts]

Correct, those are the 2 issues we've experienced; even for small files and small projects (my "small" project has 30 classes, no framework, each class is quite simple, many just Entities with setters and getters. For context, it's for a few blog posts about some design patterns I use so mostly theoretical implementations)

No, the analysis does not update until after the save is completed. So I'll fix the bug, hit save, and the error (red-squiglies) will remain until after the save is complete. And when I say after, it's not instant on save. There's a lag there too in it updating. Which I forgot. Could mean the async call is also being temporarily blocked perhaps?

[SanderRonde]

Hmm that's very strange. I'll hopefully have a debug-log collector in the extension soon to debug the first issue.

From what you're saying about the second bug it sounds like it's going well. So if I read this correctly what happens is:

• Invalid code, triggers red squiggle
• You fix the bug, hit save - the little "unsaved" icon is still there
• The PHPStan check starts. Note that this uses on-disk files, no virtual unsaved ones.
• After the check completes the squiggles disappear, the unsaved icon also does.

This means that, since the squiggles disappeared, PHPStan was executed with the non-bug-containing version of the file on disk. This means that the save did actually go through even though the file is for some reason marked as unsaved while executing the check. So this sounds like a visual-only bug. Still no clue what's causing it but I guess this is already a lot better than it actually not saving. Will get back to you on this, this might also be easier to prove in debug logs.

[lukewatts]

Let me know when that debugger is added and I'll be happy to test again. Thanks!

[SanderRonde]

Alright I've created and published version 3.2.19. Could you use that and send me the debug data using the PHPStan: download debug data command? Any file paths etc should be sanitized but feel free to have a look over and remove anything sensitive that might be in there. It only reports on (sanitized) file paths and hashes of file contents in order to compare whether they were equal. Thanks in advance!

[lukewatts]

Thanks for this. I'm still on Christmas holiday so I can't try this yet but I'll be back home the weekend of the 2nd. I'll try it then