Performance problems with uncached stub files. Is this expected?

[calvinalkan]

Hello,

I'm using WordPress stubs on a pretty big codebase. I'm experiencing big performance drops when referencing the stub file in psalm config which is somewhat expected because that stub file contains 100k lines of WordPress stubs.

With the stub file included in the config:

• Running vendor/bin/psalm --no-cache takes around 16 seconds.
• vendor/bin/psalm takes 0.21 seconds.
• changing a single line and running vendor/bin/psalm --diff takes roughly 16 seconds again.

Now without the stub file included.

• Running vendor/bin/psalm --no-cache takes around 6.5 seconds.
• vendor/bin/psalm takes on the cached contents takes the same 0.21 seconds.
• changing a single line and running vendor/bin/psalm --diff takes roughly 1.2 seconds.

This brings me to the conclusion that stub files are not cached. Is this the expected behavior?

If yes, is there anything we can do to circumvent it? I'm basically waiting all the time for psalm to parse the same stub file again that never changes because it lives in /vendor anyway. On the command line, this is somewhat okay, however, it makes the PHPStorm integration completely unusable.

Let me know if I can provide more details.

[psalm-github-bot]

Hey @calvinalkan, can you reproduce the issue on https://psalm.dev ?

[calvinalkan]

No, it's not a user-facing issue.

[calvinalkan]

Including the stub file directly in a custom bootstrap file that I reference in the psalm config cuts this time on a rescan down to 7 seconds. Still, why does the scan time increase that much if I edit a file that does not reference any functions or classes in the stub file at all?

// psalm-bootstrap.php

<?php

require dirname(__DIR__) . '/vendor/php-stubs/wordpress-stubs/wordpress-stubs.php';

[orklah]

It's probably not expected, but the original author has left the project for the most part so I couldn't be sure.

It would be great if you could take a look at it to check what could be going wrong!

[calvinalkan]

@orklah Can you point me to the right class or directory? I'm completely unfamiliar with the codebase.

[orklah]

Sorry, I won't be able to help you much on this one, I never tried to go through the cache yet.

What I can tell you is that it starts here:

psalm/src/Psalm/Internal/Cli/Psalm.php

Line 616 in 65fffd2

$no_reflection_cache = isset($options['no-reflection-cache']);

This is the place where Cache providers are initialized. They seem to each have their own goal, so you may be able to identify the one that caches stubs and go from there

[calvinalkan]

@orklah Thank you, I'll have a look and see if I can understand it. Currently using the method in #7570 (comment) yields acceptable-ish performance

[DragosMocrii]

Including the stub file directly in a custom bootstrap file that I reference in the psalm config cuts this time on a rescan down to 7 seconds. Still, why does the scan time increase that much if I edit a file that does not reference any functions or classes in the stub file at all?

// psalm-bootstrap.php

<?php

require dirname(__DIR__) . '/vendor/php-stubs/wordpress-stubs/wordpress-stubs.php';

how did you include this file in the psalm.xml ?

[calvinalkan]

@DragosMocrii by using the "autoloader" option in psalm.xml

[DragosMocrii]

@DragosMocrii by using the "autoloader" option in psalm.xml

Thanks. I tried your method and was still getting poor performance. Switched to PHPStan and is way faster for me. I believe the latter has a better way to resolve stubs with its symbol discovery mechanism.