[2.2.3 perf regression fix] PackageDependencyResolver: memoize resolvePackage per file

[SanderMuller]

Follow-up to #5933, which introduced PackageDependencyResolver.

Problem

resolvePackage() maps a file to its owning Composer package by scanning every install path with str_starts_with(). It is called from NodeDependencies::getPackageDependencies() once per dependency file of every analysed file, so the same vendor files are resolved over and over, and each call is linear in the number of installed packages. The install-path map (getInstallPathToPackage()) is already memoized, but the per-file lookup was not.

A cold profile of a project with a large dependency tree (~265 installed packages, ~1800 files) shows 236,905 resolvePackage() calls and 62.9M str_starts_with() comparisons, all new in 2.2.3.

Fix

Memoize the result per file. Most dependency files belong to no project package (they are PHPStan's own bundled dependencies), so the common null result is cached too, since it otherwise pays a full scan on every call. PackageDependencyResolver is a singleton service, so the cache persists across all files in a worker. Same approach as 200a203 (DependencyResolver: reduce duplicate work).

Output is unchanged: the cache is keyed by file, and a file's owning package cannot change during a run.

Result

Cold analysis of the same project, result cache cleared before each run, interleaved across builds and repeated to be robust to machine load:

build	cold CPU (user+sys)	cold wall
2.2.2	201 s	29 s
2.2.3	293 s	40 s
2.2.3 + this change	215 s	30 s

This recovers about 85% of the regression. A residual ~7% above 2.2.2 remains after this change and is not resolvePackage (memoizing it does not move it further); it is elsewhere in the 2.2.2..2.2.3 range and I am narrowing it down separately.

The full test suite, self-analysis and the coding standard pass. The result-cache e2e scenarios behave identically with and without the change, as expected for a pure memoization.

[staabm]

how to reproduce the problem?

[SanderMuller]

how to reproduce the problem?

Cold analysis of a project with a large dependency tree, comparing 2.2.2 to 2.2.3. On a project here (~265 installed packages, ~1800 files, level 7), interleaved cold runs (result cache cleared before each, repeated to be robust to machine load):

build	cold CPU (user+sys)	cold wall
2.2.2	201 s	29 s
2.2.3	293 s	40 s
2.2.3 + this PR	215 s	30 s

The same holds single-process (--debug): 141 s / 219 s / 155 s. A cold profile of 2.2.3 shows 236,905 resolvePackage() calls and 62.9M str_starts_with() comparisons, all new in 2.2.3, with the same vendor files resolved repeatedly. Memoizing per file recovers about 85%. I also measured a build with package-dependency tracking fully disabled and it was no faster than this PR, so the memo captures the recoverable cost.

On the memory report in #14892: this PR is a CPU fix. It does not reduce the stored packageDependencies map, so I would not expect it to move peak memory, and in my measurements peak memory was the same for 2.2.2, 2.2.3, this PR, and even with package tracking fully off. My project is smaller than the one in #14892, so I could not reproduce that memory delta here to validate a memory-side change. That looks like a separate fix targeting the per-file package-dependency storage.

There is also a residual ~7% above 2.2.2 that remains after this PR and is not resolvePackage (disabling it entirely does not move it further), so it is elsewhere in the 2.2.2..2.2.3 range; I am narrowing that down separately.

[ondrejmirtes]

Thank you!