Optimize FileTypeMapper for huge PHPDocs#2582
Conversation
|
You've opened the pull request against the latest branch 1.11.x. If your code is relevant on 1.10.x and you want it to be released sooner, please rebase your pull request and change its target to 1.10.x. |
|
the new version of phpstan is 3x quicker at analyzing one of our packages (1.10.27 => 1.10.32) with an empty result cache I looked at this problem for so long and got tunnel visioned on the parser itself rather than looking higher level that is an amazing speed up, really great work @ondrejmirtes |
|
Yeah, I'm on the optimization streak right now 😊 In 1.10.x-dev (not yet released) there's one more commit with a speedup 😊 |
|
Couldn't sleep yesterday because of the heat and a storm. Was checking github, saw your performance commits, couldn't sleep because of excitement about them then 😅 |
|
@herndlm I'm so sorry 😀 I couldn't sleep and had to finish it because I finally saw what the bottleneck was 😀 |
|
That's great, I'm currently travelling, so I was only looking at commits :) |
So we parsed the same PHPDoc all over again through
$this->phpDocStringResolver->resolvebecause it's repeatedly needed in$typeMapStackcallbacks.So with these changes, we first go through all the PHPDocs in the file (+ in files of used traits), parse them and save the AST objects to
$phpDocNodeMap. This map is then used in$typeMapStackincreateNameScopeMapinstead of parsing the PHPDocs hundreds of thousands of times again.The Carbon performance issue is solved with this change.
The disadvantage is that
createPhpDocNodeMaphas a lot of duplicated code withcreateNameScopeMap, but I don't know how to make it nice.We could do a bit more -
$this->phpDocStringResolver->resolveis still called increateResolvedPhpDocBlockand ingetTypeAliasesMapand at that point we already havePhpDocNodeavailable, but I want to try out how the current version works, and leave this optimization for another day, maybe.