Performance - optimize run with result cache

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

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

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.

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

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.

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.

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

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

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

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

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)

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.

php-parsing of phpstorm stubs could maybe be cached. other than that I think we checked all low hanging fruits

Yup, caching could somehow be added around $this->phpstormStubsSourceStubber in BetterReflectionSourceLocatorFactory. Similarly to what I did in OptimizedDirectorySourceLocator and OptimizedSingleFileSourceLocator.

Make the environment a dynamic container parameter

Narrow the container cache key to the referenced %env.* variables

Navigation Menu

Repository navigation

Performance - optimize run with result cache #14072

Feature request

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Performance - optimize run with result cache #14072

Description

Feature request

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

Activity

staabm commented on Feb 14, 2026

ondrejmirtes commented on Feb 14, 2026

staabm commented on Feb 14, 2026

staabm commented on Feb 14, 2026

staabm commented on Feb 14, 2026

staabm commented on Feb 14, 2026

ondrejmirtes commented on Feb 14, 2026

ondrejmirtes commented on Feb 14, 2026

staabm commented on Feb 14, 2026

staabm commented on Feb 14, 2026

ondrejmirtes commented on Feb 14, 2026

staabm commented on Feb 14, 2026

ondrejmirtes commented on Feb 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions