Reduce significantly PHPStan running time by enabling bleeding edge features

The log looks strange https://dispatcher.drupalci.org/job/drupal_patches/160397/artifact/jenki...

How to measure?

PHPStan: passed

----------------------------------------------------------------------------------------------------
................................ 32 / 32 (100%)


Time: 12.3 secs; Memory: 6MB

The "non-text-only" log of a CI run has start and end times in front of every line, so let's take that as a measurement for now?

Grabbed three random core issues from the first page of the issue list and came up with:

1. 00:03:28.959 ----------------------------------------------------------------------------------------------------
   00:03:28.959 
   00:03:28.959 Running PHPStan on *all* files.
   00:06:10.089 
   00:06:10.095  [OK] No errors                                                                 
   00:06:10.095 
   00:06:10.136 
   00:06:10.136 PHPStan: passed
   00:06:10.136 
   00:06:10.136 ----------------------------------------------------------------------------------------------------
   00:06:13.736 ................................ 32 / 32 (100%)
   00:06:22.735 
   00:06:22.735 
   00:06:22.736 Time: 12.56 secs; Memory: 6MB

   https://dispatcher.drupalci.org/job/drupal_patches/160425/consoleFull

   Time spend in PHPStan-land: ~2m54s

2. 00:03:27.234 ----------------------------------------------------------------------------------------------------
   00:03:27.234 
   00:03:27.234 Running PHPStan on *all* files.
   00:06:05.597 
   00:06:05.603  [OK] No errors                                                                 
   00:06:05.603 
   00:06:05.646 
   00:06:05.646 PHPStan: passed
   00:06:05.646 
   00:06:05.646 ----------------------------------------------------------------------------------------------------
   00:06:09.175 ................................ 32 / 32 (100%)
   00:06:17.933 
   00:06:17.933 
   00:06:17.934 Time: 12.24 secs; Memory: 6MB
   

   https://dispatcher.drupalci.org/job/drupal_patches/160417/consoleFull

   Time spend in PHPStan-land: ~2m50s

3. 00:03:39.450 ----------------------------------------------------------------------------------------------------
   00:03:39.450 
   00:03:39.450 Running PHPStan on *all* files.
   00:06:20.148 
   00:06:20.154  [OK] No errors                                                                 
   00:06:20.154 
   00:06:20.195 
   00:06:20.195 PHPStan: passed
   00:06:20.195 
   00:06:20.195 ----------------------------------------------------------------------------------------------------
   00:06:23.781 ................................ 32 / 32 (100%)
   00:06:32.523 
   00:06:32.523 
   00:06:32.524 Time: 12.28 secs; Memory: 6MB
   

   https://dispatcher.drupalci.org/job/drupal_patches/160431/consoleFull

   Time spend in PHPStan-land: ~2m53s

Now for this issue:

1. 00:01:42.289 ----------------------------------------------------------------------------------------------------
   00:01:42.289 
   00:01:42.289 Running PHPStan on *all* files.
   00:03:06.481 
   00:03:06.481  [OK] No errors                                                                 
   00:03:06.481 
   00:03:06.481 
   00:03:06.481 PHPStan: passed
   00:03:06.481 
   00:03:06.481 ----------------------------------------------------------------------------------------------------
   00:03:07.151 ................................ 32 / 32 (100%)
   00:03:15.917 
   00:03:15.917 
   00:03:15.918 Time: 12.3 secs; Memory: 6MB
   

   https://dispatcher.drupalci.org/job/drupal_patches/160397/consoleFull

   Time spend in PHPStan-land: ~1m33s

So that looks like a really nice speed-up.
Of course, n is too small, calculations too sloppy, etc., but I'm going or an RTBC for this one.

EDIT: The only thing that might be of concern is that "bleeding edge" is supposed to land somewhere in the next releases? If so, we then have that performance in a normal version and the then-bleeding edge might be something that shoots us in the foot?

To many unknowns for me there, but still, shaving off 40(?)% of our PHPStan-land-time for all testruns on d10 is enough to keep my RTBC standing for now.

The only thing that might be of concern is that "bleeding edge" is supposed to land somewhere in the next releases? If so, we then have that performance in a normal version and the then-bleeding edge might be something that shoots us in the foot?

This is true but we'd just need to remove it again? The maintainer said this should be in phpstan 2.0, so should we open a follow-up to remove bleeding edge when we upgrade to phpstan 2?

Very +1 for trying this. I have changed computer in the past couple of months, but before that I wasn't able to run phpstan locally without limiting the number of processes, and I think @xjm has a similar issue now, so this will have a significant material effect on committing core patches apart from the general speedup for hopefully everyone.

Yeah #6 is also fair enough for me.

All for this change, my (very beefed up) dev-laptop almost takes off during a full PHPStan run, just wanted to point out what _might_ happen. That's fully addressed now :)

Backported to 10.0.x since this is core's phpstan conf and we can back this out the moment we need to.

Committed and pushed a4bda74289 to 10.1.x and 19131be388 to 10.0.x. Thanks!