Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Combing SQL Coverage Data unacceptably slow #761
Describe the bug
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.
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.