SanderRonde / phpstan-vscode

PHPStan plugin for VSCode
https://marketplace.visualstudio.com/items?itemName=SanderRonde.phpstan-vscode
MIT License
47 stars 8 forks source link

Increase the interval between child process checks #105

Closed rdeago closed 2 months ago

rdeago commented 2 months ago

While investigating #103 on my Windows 11 system, I noticed dozens of WMIC.exe instances spawn during each run of PHPStan. They were so pervasive as to make WmiPrvSE.exe, the service WMIC uses to query system information, take up to 65% (once even 94%) of a 32-thread, 13th-gen Core i9.

I eventually found out what's spawning WMIC like crazy: it's ps-tree, called by the Process class every 100ms (the call to ps-tree is actually in function _getChildPids, some lines below).

May I suggest to increase the checking interval in Process::constructor? 100 milliseconds look pretty overkill to me. 1 second should be good enough as a resolution for process timeouts, especially when checks come at such a cost in terms of performance.

SanderRonde commented 2 months ago

Thanks for looking into this! 100ms is indeed overkill. The scenario this guards for is the scenario where a user launches PHPStan, then closes the editor mid-check and re-launches the editor without having rebooted the machine. It should then kill the remaining child PIDs in the zombie killer. I think doing two checks (one at start, one after PHPStan has possibly spawned workers) is enough for this relatively rare case.

SanderRonde commented 2 months ago

Fix has been published in v3.2.7

Balkoth commented 2 months ago

@SanderRonde I am on v3.2.7 and am still seeing out of control creation of wmic processes. Only happens within VSCODE, if i call phpstan from the command line, all is well.

SanderRonde commented 2 months ago

Hmm interesting, will look into this when I'm on a windows machine again. It should only query the process list 3 times per check now (once during creation, once after 10s, once during killing). And it should only create a single wmic process. Just to get an idea, how out of control is it? As in how many processes are being spawned and how much CPU is being used? Might help me spot it once I manage to reproduce it.

Balkoth commented 2 months ago

I can not count them, because they are so rapidly created and destroyed that the whole system hangs while the scan is active. CPU is an i7-10850H at 100% usage.

PHPSTAN-Settings:

"phpstan.binPath": "C:\\Program Files\\Composer\\vendor\\bin\\phpstan.bat",
"phpstan.configFile": "C:\\Work\\Config\\phpstan.neon",
"phpstan.memoryLimit": "4G",
"phpstan.timeout": 50000,
"phpstan.checkValidity": true,
"phpstan.showProgress": true,
rdeago commented 2 months ago

Just in case it might help, I tried changing the 100-millisecond timeout of version 3.2.6 to 999 milliseconds, without any other modification.

(Why 999? Because I used a hex editor on the minimized distribution 😁)

The flood of WMICs decreased accordingly, of course.

So there seems to be something in version 3.2.7 that triggers ps-tree way more frequently than anticipated... but what? 🤔

SanderRonde commented 2 months ago

Oh wow I'm stupid... I've used setInterval(..., 0) instead of setTimeout(..., 0). No wonder it's spawning so many instances...

Will fix immediately. Thanks for flagging!

rdeago commented 2 months ago

OMG setInterval! I stared at that piece of code for like ten minutes and it totally eluded me. 🙈

Oh wow I'm stupid

Welcome to the club! 🤣

SanderRonde commented 2 months ago

Fix is live under version 3.2.8!

Yeah I had the exact same, was thinking "how could 2 calls possibly do more than one every 999ms". Surprised this didn't cause a massive influx of github issues.

rdeago commented 2 months ago

I guess people's PCs were too busy querying WMI to let them open issues on GitHub. 🥲

Balkoth commented 2 months ago

Seems fixed to me now. Thank you for the really quick response. 👍