SymfonyContainerResultCacheMetaExtension optimization

[xificurk]

The cache busting strategy implemented by the extension attempts to avoid unnecessary invalidations by calculating the hash from the parsed parameters and services used within phpstan-symfony logic. This addresses the case when the container XML have been regenerated and changed, but not in an significant way impacting the result cache (originally discussed in #255).

The problem is that on large DI containers this parsing, normalizing and hashing is not exactly cheap:

This PR adds a simple filesytem cache for the calculated hash to avoid this cost - the hash is recalculated from the parsed services/parameters only when the underlying XML changes.

[staabm]

@Wirone@ruudk you both contributed into the discussion of this feature. could you have a look at this proposal?

@xificurk how much does this change/improve your real world project? could you send some before/after 'hyperfine' numbers (measured without profiler-extension overhead)?

[xificurk]

Measured on top of #487 (comment)

In combination with the lazy maps, this PR eliminates the initialization of ServiceMap and ParameterMap in the main process as well, leading to further improvement (10 run median) 8.77s -> 8.18s on the same simple test bin/phpstan analyse bin/console.php

[staabm]

atm we are focused on shipping the next phpstan release. I will comeback to this PR after the release is out

[staabm]

The cache busting strategy implemented by the extension attempts to avoid unnecessary invalidations by calculating the hash from the parsed parameters and services used within phpstan-symfony logic. This addresses the case when the container XML have been regenerated and changed, but not in an significant way impacting the result cache

I think we need a test in which the container is changed in a non-significant way, but the cache is still used

[xificurk]

The cache busting strategy implemented by the extension attempts to avoid unnecessary invalidations by calculating the hash from the parsed parameters and services used within phpstan-symfony logic. This addresses the case when the container XML have been regenerated and changed, but not in an significant way impacting the result cache

I think we need a test in which the container is changed in a non-significant way, but the cache is still used

@staabm I can take a look at that, but want to be clear that what you quoted is the description of the current behavior present in the master. This MR is a performance optimization of that described strategy.

[staabm]

I see. I am fine than. thanks for noting.

[staabm]

thanks anyone inolved!