-
-
Notifications
You must be signed in to change notification settings - Fork 385
Represent CoverageData in objects #1105
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
Conversation
fc584c4 to
466072b
Compare
|
Is the only reason you're still considering this a draft/proof of concept because the tests need updating? |
yes |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1105 +/- ##
============================================
+ Coverage 88.41% 88.59% +0.18%
- Complexity 1387 1404 +17
============================================
Files 102 105 +3
Lines 4712 4780 +68
============================================
+ Hits 4166 4235 +69
+ Misses 546 545 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
tested a different case on the phpstan-src codebase: running phpstan-src@8f9490ecc6 before this PR (37047b5): with this PR (3e53a48) |
|
After a few more tests, I think the optimization is only substantial when phpunit is invoked with |
|
I think we can achieve similar things for regular line-coverage.. will prepare a separate PR |
thesis is, that we need less memory when processing big projects
in phpstan-src I can see the coverage producing test-runs to consume ~3GB of data.
my gut feeling is, that if we would consume less data we would automatically get faster, because we need less memory allocations
running phpstan-src@8f9490ecc6
before this PR (37047b5):
with this PR (1b73b3c)