Performance - optimize run with result cache

[ondrejmirtes]

Feature request

What happens with the result cache: we get list of modified files, ExportedNodeResolver decides whether the modifications were only inside function bodies. If not, we also add dependent files to the list of files to analyse. If only function bodies were modified, we only analyse the modified file. Analysis runs for the list of files to analyse, results get merged with the rest from the result cache.

PHPStan only takes a few seconds to compute all this, but we never ran Blackfire to see if there are bottlenecks to conquery. In order to run with result cache even with --debug (to enforce single process), these lines in the ResultCacheManager have to be commented out:

		if ($debug) {
			if ($output->isVeryVerbose()) {
				$output->writeLineFormatted('Result cache not used because of debug mode.');
			}
			return new ResultCache($allAnalysedFiles, true, time(), $this->getMeta($allAnalysedFiles, $projectConfigArray), [], [], [], [], [], [], [], [], [], $currentFileHashes);
		}

Did PHPStan help you today? Did it make you happy in any way?

No response

[staabm]

Patched phpstan/phpstan-src@ac46a7f 2.1.x with

diff --git a/src/Analyser/ResultCache/ResultCacheManager.php b/src/Analyser/ResultCache/ResultCacheManager.php
index 3b929cc59e..702d657082 100644
--- a/src/Analyser/ResultCache/ResultCacheManager.php
+++ b/src/Analyser/ResultCache/ResultCacheManager.php
@@ -129,7 +129,7 @@ final class ResultCacheManager
                        }
                        $currentFileHashes[$analysedFile] = $this->getFileHash($analysedFile);
                }
-               if ($debug) {
+               if (false && $debug) {
                        if ($output->isVeryVerbose()) {
                                $output->writeLineFormatted('Result cache not used because of debug mode.');
                        }

and analyzing without further file changes (100% result cached) results in

-> we are dominated by shipmonks/dead-code-detector

https://blackfire.io/profiles/2bf8483a-b63f-461b-959d-2d340a554761/graph

---

after removing shipmonks/dead-code-detector

composer remove shipmonk/dead-code-detector

diff --git a/build/phpstan.neon b/build/phpstan.neon
index 3469b8fca5..235b4f0d3b 100644
--- a/build/phpstan.neon
+++ b/build/phpstan.neon
@@ -4,7 +4,6 @@ includes:
        - ../vendor/phpstan/phpstan-phpunit/extension.neon
        - ../vendor/phpstan/phpstan-phpunit/rules.neon
        - ../vendor/phpstan/phpstan-strict-rules/rules.neon
-       - ../vendor/shipmonk/dead-code-detector/rules.neon
        - ../conf/bleedingEdge.neon
        - ../phpstan-baseline.neon
        - ../phpstan-baseline.php

.. we are dominated by regex ast analysis when analyzing without further file changes (100% result cached)

https://blackfire.io/profiles/7849920b-27d4-4688-9d54-a677ce5a7804/graph

---

after a single file change (still shipmonks/dead-code-detector disabled)

diff --git a/src/Analyser/Error.php b/src/Analyser/Error.php
index 9af5f2b297..12114a1406 100644
--- a/src/Analyser/Error.php
+++ b/src/Analyser/Error.php
@@ -337,6 +337,7 @@ final class Error implements JsonSerializable
                        $properties['metadata'] ?? [],
                        $properties['fixedErrorDiff'] ?? null,
                );
+               $x = 1;
        }
 
        public static function validateIdentifier(string $identifier): bool

PHPStan\Analyser\FileAnalyserCallback::__invoke() dominates

https://blackfire.io/profiles/8e36da86-90ba-4527-a4f8-e7a2c38121f5/graph

[ondrejmirtes]

Thank you, I wanted data like that.

after removing shipmonks/dead-code-detector we are dominated by regex ast analysis when analyzing without further file changes (100% result cached)

This worries me a bit. Is this validating ignoreErrors in neon? That should not be happening if the DIC is compiled.

Can't think of another reason for this to happen.

[staabm]

This worries me a bit. Is this validating ignoreErrors in neon?

path is (yes its validating ignores)

I think the root cause is that the container name changes on some phpstan invocation

[staabm]

it does not happen every time, but I can see sometimes a few more variables in the array beeing used for building the container key.

[staabm]

I can reproduce now. it happens after you cd between folders and run PHPStan again.

see https://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html

OLDPWD
The previous working directory as set by the cd builtin.

[staabm]

I see another case now. the container invalidates as soon as you re-size the shell window, because a ENV var exists which defines the LINES and COLUMNS in the window

[ondrejmirtes]

Loo! We could unset it in ResultCacheManager like we do with _ or SHLVL.

[ondrejmirtes]

So what's slowing it down if dead-code-detector is not there, result cache is up to date, DIC is not regenerated?

[staabm]

So what's slowing it down if dead-code-detector is not there, result cache is up to date, DIC is not regenerated?

phpstan/phpstan-phpunit#277

[staabm]

So what's slowing it down if dead-code-detector is not there, result cache is up to date, DIC is not regenerated?

after all linked PRs are merged we bottleneck on PHPParser and ExistingNamesInUseRule::processNode:

a)

---

b)

[ondrejmirtes]

Be a bit careful about these assumptions, the rule might just be the first to hit something uncached, the ones after it might be at an advantage.