-
-
Notifications
You must be signed in to change notification settings - Fork 373
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
Coverage Report cache makes PHP report memory usage explode #1009
Labels
Comments
All of your suggestions make sense to me, at least as short-term solutions. Once #874 has been implemented, we should have a long-term solution. |
This was referenced Sep 12, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Changes merged in #1005 and released
10.1.3
madeReport\PHP
unusable as now it always consumes too much memory.Our
coverage.php
file went from29 Mb
to737 Mb
, re-processing it withphpcov
or any other tool skyrockets the memory used from< 1 Gb
to> 4 Gb
, with no control over it and, most important, no real benefit for the purposes of re-processing many times theReport\PHP
file.#1005 is good because when you use many
Report\*
, theDirectory
is build only once and PHPUnit's report generation is faster, butReport\PHP
should serialize theCodeCoverage
object without the$this->cachedReport
property filled.I suggest the following improvements:
Report\PHP
should serialize theCodeCoverage
object with the cache cleared using a new@internal
API such asCodeCoverage::clearCache
(different from the currently presentCodeCoverage::clear
which has another purpose)PHPUnit\Runner\CodeCoverage
should generate theReport\PHP
as first in the list, so that when it's processed no cache has been already built; the aforementioned APICodeCoverage::clearCache
would be practically useless, but it's still needed to ensure consistency ofphp-code-coverage
packageSebastianBergmann\PHPCOV\Command
should generate theReport\PHP
as first in the list for the same reasonThe text was updated successfully, but these errors were encountered: