-
-
Notifications
You must be signed in to change notification settings - Fork 386
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
base: main
Are you sure you want to change the base?
Conversation
|
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.82% 88.98% +0.15%
- Complexity 1391 1408 +17
============================================
Files 98 101 +3
Lines 4655 4712 +57
============================================
+ Hits 4135 4193 +58
+ Misses 520 519 -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)