Improve laziness of container XML parsing#487
Conversation
| public function getService(string $id): ?ServiceDefinition; | ||
|
|
||
| public static function getServiceIdFromNode(Expr $node, Scope $scope): ?string; | ||
| public function getServiceIdFromNode(Expr $node, Scope $scope): ?string; |
There was a problem hiding this comment.
I think this is a BC break, given the fact that the interface has @api. If someone implements the interface his code will break.
Same exist for ParameterMap ; so I'll need @ondrejmirtes review.
There was a problem hiding this comment.
Rewritten to keep BC
|
Yeah, removing the |
|
@ondrejmirtes Yes, I'll rework this to maintain BC. Removing the static would make sense for 3.0 - all the existing calls are on a dynamically resolved instance. No true static calls exist and given the implemented logic, they should not exist. |
|
@xificurk please also provide a profiler screenshot / hyperfine perf numbers so we can see the impact of this PR |
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
@staabm As discussed in phpstan/phpstan-src#5538 I am targetting few file partial analysis on larger code base. A test on a very simple file |
Awesome 🤩 |
| $lazyParameterMap::$parameterMapFactory = $parameterMapFactory; | ||
| $lazyParameterMap::$parameterMap = null; |
There was a problem hiding this comment.
can we move this into a __construct of the above inline class?
same in LazyServiceMap
There was a problem hiding this comment.
Not as long as LazyParameterMap::__construct remains private. The private constructor is intentional - it prevents any 3rd party inheritance.
What is the remaining 8 seconds taken by? |
4 participants
Parsing the XML into the DTOs is a costly operation on large Kernels. This PR defers the ServiceMap and ParameterMap initialization until the first use of their content.