Optimize FileTypeMapper for huge PHPDocs

[ondrejmirtes]

So we parsed the same PHPDoc all over again through $this->phpDocStringResolver->resolve because it's repeatedly needed in $typeMapStack callbacks.

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 $typeMapStack in createNameScopeMap instead of parsing the PHPDocs hundreds of thousands of times again.

The Carbon performance issue is solved with this change.

The disadvantage is that createPhpDocNodeMap has a lot of duplicated code with createNameScopeMap, but I don't know how to make it nice.

We could do a bit more - $this->phpDocStringResolver->resolve is still called in createResolvedPhpDocBlock and in getTypeAliasesMap and at that point we already have PhpDocNode available, but I want to try out how the current version works, and leave this optimization for another day, maybe.

[phpstan-bot]

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.

[mad-briller]

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

[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 😊

[herndlm]

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 😅

[ondrejmirtes]

@herndlm I'm so sorry 😀 I couldn't sleep and had to finish it because I finally saw what the bottleneck was 😀

[herndlm]

That's great, I'm currently travelling, so I was only looking at commits :)