-
-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enabling staabm/phpstan-dba
significantly increases garbage collection activity
#667
Comments
Thanks for the report. Is the problem reproducible in a minimal repo or similat? |
As of right now, I haven't been able to reproduce this on smaller repositories. For instance, running PHPStan just on certain subfolders where we have our SQL queries, runs through in a few seconds and garbage collection activity is similar with and without the extension enabled. |
which phpstan-dba config options do you use? maybe you can use tideways to look into where most memory consumption happens, so we can get an idea where all the memory trash is generated. it might also make sense to disable rules and extensions to narrow it down further |
The config is more or less the default. Setting debug false/true doesn't make a difference
I try to pinpoint this to specific rules/extensions but this might take a while as every run takes a few minutes. Will report back once I have more info. |
Alright, I figured out what is causing this. If I fully remove
and only configure this one service
then the run is suddenly 6min longer. The bigger the repository to analyze the bigger the impact. |
Thanks for looking into it. I guess its the same problem as https://phpstan.org/blog/preprocessing-ast-for-custom-rules |
could you please try whether #670 at least helps a bit to reduce your pain? |
and please also try #671 at best also give your project a try with both PRs applied at the same time, so we know about the impact of each in isolation and also the combination |
Apologies, somehow I missed the second PR this morning. Unfortunately, no improvements.
|
Could you have a look into a memory profile to see which objects leak? |
So, I have been looking into this a bit. Looks like most profilers just tell you which method/function leaks the memory but not which objects are leaked. The one profiler which provides that kind of info is php-meminfo. I was able to generate a profile with our regular setup and one where I disabled the There are definitely some types where the instances count multiplies by a lot like
With PreviousConnectingVisitor enabled
Without PreviousConnectingVisitor
|
do you still see this problem in PHPStan 2.x? |
and could you please try #729 which is a new attempt to less references between AST nodes |
Nice another win! Running PHPStan with |
thanks, released as 0.3.3 I am out of ideas for further improvemens. could you do another measure like #667 (comment) ? another question: could you have a look of a phpstan run not at all loading phpstan-dba (regular vs. disabled-gc), so we can see whether plain phpstan might also need some GC quirks |
ok, one last idea you could check :) |
No improvements, but on the bright side, it looks like all/most of the overhead is now coming from elsewhere.
Thanks a lot for looking into this! I'll play around with disabling the other extensions to see where the remaining ~1min of added time is coming from and will report it there. |
Thats great news. Hopefully none of my other extensions responsible for the remaining stuff ;-) |
We noticed that since we enabled
staabm/phpstan-dba
in our project, a full PHPStan run without cache takes significantly longer than without it.Running it with the extension
Running it without the extension
I triggered a trace with Tideways to see why this suddenly takes so much longer and it turns out that about 6min of the run is spent on garbage collection. Turning garbage collection off results in a significant performance boost.
Running it with the extension
Running it without the extension
Is there any chance you encountered similar effects and already have an idea what could cause this? Otherwise, I'll look into some memory profiling in the next days to see if I can find a cause for this. Happy to share additional info but not really sure what might actually be helpful here.
The text was updated successfully, but these errors were encountered: