-
-
Notifications
You must be signed in to change notification settings - Fork 428
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
Combing SQL Coverage Data unacceptably slow #761
Comments
This issue should really have label:5.0-pre-release |
Okay, some more information. It turns out that the new context-based coverage is about 50-60 times the data compared to the context-free coverage. Our arc table now has 9.5M entries, but there are only 172k unique We have been working all morning on optimizing combining and have come up with the following script that runs in 2:30 minutes, so it is somewhere between 20-30 times faster then the current master solution.
We are working on a PR for this. But it will require a change on how combining is done, since we are considering all parts at once instead of one at a time. |
I have been able to integrate the above using the existing APIs. A few tests are still failing, but I am planning to create a clean PR for this issue. |
PR: #765 |
Speedup is really just about 2x. There was another bug that caused a slowdown for us. |
Describe the bug
Generating a combined coverage report is about 50-60 times slower with SQL-based coverage data than with JSON.
To Reproduce
coverage master with sql data coverage. You need a sizable set of coverage data.
Additional context
We are combining about 100-200 coverage files into one large one. The resulting SQL coverage file is about 390MB. It used to be able to combine those files in about 1 minute. Now it takes somewhere between 50-60 minutes.
The reason for the inefficiency is obvious: It combines files through the regular coverage measurement recording APIs, which are inappropriate to use here, since they cause one transaction per arc. SQL should be used in proper ways with do bulk reading and inserts.
The text was updated successfully, but these errors were encountered: