Feature request
We currently set hard limit in the configuration (with maximumNumberOfProcesses). Recently I wanted to check if we can get rid of this hardcoded limit and allow PHPStan to determine available CPUs from Gitlab CI runner on Kubernetes. Unfortunately, it seems like it's determining CPUs with /proc/cpuinfo which contains real amount of CPUs on machine:
processor : 23
vendor_id : GenuineIntel
The problem is that Gitlab runner's kubernetes executor (pod) has own limits applied, so the effect is that PHPStan spawns too many processes, while most of them is limited by cluster and end up with timeout.

The solution could be improving CpuCoreCounter so it can determine available CPU based on:
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us (in our case: 400000)
cat /sys/fs/cgroup/cpu/cpu.cfs_period_us (in our case: 100000)
The real amount needs to be calculated with quota / period.
Feature request
We currently set hard limit in the configuration (with
maximumNumberOfProcesses). Recently I wanted to check if we can get rid of this hardcoded limit and allow PHPStan to determine available CPUs from Gitlab CI runner on Kubernetes. Unfortunately, it seems like it's determining CPUs with/proc/cpuinfowhich contains real amount of CPUs on machine:The problem is that Gitlab runner's kubernetes executor (pod) has own limits applied, so the effect is that PHPStan spawns too many processes, while most of them is limited by cluster and end up with timeout.
The solution could be improving
CpuCoreCounterso it can determine available CPU based on:cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us(in our case: 400000)cat /sys/fs/cgroup/cpu/cpu.cfs_period_us(in our case: 100000)The real amount needs to be calculated with
quota/period.