[janedbal]

Problem

restore() decodes the whole collectedData section into the main process before the analysis starts. Only the rules on CollectedDataNode need that data, after the analysis, in the main process. Until then it sits in memory for the whole run, and every forked worker inherits it. On a project with a collector-heavy extension this is the largest section of the cache by far: Dead Code Detector stores every member usage in it, hundreds of megabytes on a large codebase. That is why DCD moved its data into its own file store (shipmonk-rnd/dead-code-detector#319) and later optimised that store (shipmonk-rnd/dead-code-detector#427). With 2.2.13 and this change both can go: DCD emits its usages through the collector API again.

Change

• An array-frame entry carries its key as a separate payload before the value, so a section can be indexed without decoding any value. Cache version bumped.
• restore() walks the collectedData section into an index (file to offset and length) and hands it out as LazyCollectedData together with the run's fresh data. That is all the workers inherit.
• save() copies the entries that stay valid byte for byte from the old file, records their positions in the new one, and serializes only the fresh entries. A warm run writes a byte-identical file.
• AnalyserResultFinalizer is the only place that decodes the section, and the decoded array lives as long as the CollectedDataNode.
• The file is opened per read; no handle survives a fork or blocks a rename on Windows. Both the reader and the copy verify the key at the offset, so a cache replaced by another run sharing the tmpDir is never copied misaligned: the save is skipped and the run reports an internal error once.
• A value that fails to unserialize used to be caught in restore(). It now surfaces in the finalizer, after the bytes were copied into the new file, so the reader discards the file and the finalizer reports an internal error (shouldReportBug: false) instead of failing on every following run.

CollectedDataNode and the Collector API are unchanged. AnalysisResult (@api) accepts the collected data as a closure so a formatter that never asks for it never decodes the section.

Numbers

phpstan-src self-analysis with DCD data in the result cache (2467 files, 88 MB cache), main process, Linux:

	before	after
restore(), warm run	200 ms, +168 MB	175 ms, +74 MB
partial run of 486 files, main process peak	486 MB	440 MB
partial run of 486 files, largest forked worker	368 MB	276 MB

The peak during the CollectedDataNode rules is unchanged; they still get the whole array. A streaming API for rules would be a separate, additive change.

Notes

• After a partial run, CollectedDataNode lists the cached files first and the re-analysed ones after them. A full run already yields worker-completion order, so nothing can depend on it.
• ResultCacheManager::process() drops workerCount on the merged result, so cached runs never print the per-worker peak. Not included here; the worker numbers above come from a one-line local fix.
• The CI jobs failing here (mutation testing, Windows PHPStan, extension and integration tests) fail the same way on Do not call a cache file that vanished mid-read corrupted #6371 and Keep the openssl cipher probe's warnings inside the probe #6372.

[phpstan-bot]

This pull request has been marked as ready for review.

[ondrejmirtes]

Thank you!