Performance issue when running on .NET Core with XUnit about altcover HOT 6 CLOSED

Without any more granular timing information, I can only speculate as to which phase of the operation is taking the time, so I'll be adding more feedback for that. Scanning the nuget cache for assembly resolution is a slow operation, like anything involving the file system, but I can think of some optimizations there that I can add for that.

from altcover.

Also, looking at your data sizes -- half a gigabyte of compressed visit data in the .0.acv file, meaning order 100 million visits, yes that will take some time to process.

Comparing it with the data I have from the altcover build, the coverage overhead from my unit tests on my desktop is about 90s for a process that ends up with a 1.6 megabyte report file and 29.5 megabytes of compressed visit data (2.3 million visits, including branches). Your ~20x larger dataset taking about ~10x longer to process says to me that at least the dominant part of the process is no worse than O(n), which means that there's not going to be an easy algorithmic fix in there.

As to a work-around, with the ~30% coverage such as you have at the moment (2808 of 8363 lines), my assessment would be that gathering branch coverage information is probably not a priority : it's when you've approached 100% coverage that it's important to know what paths haven't been exercised, because before then, you can usually spot them from the uncovered lines (implicit empty "else" blocks aside). Setting /p:AltCoverOpenCover=false should cut down the dataset size, and thus speed the post-processing stage.

Also, if there is code not being covered that is not interesting as far as coverage goes (e.g. machine generated boiler-plate), that would be a candidate for exclusion (e.g by filtering on the [CompilerGenerated] attribute).

from altcover.

I've managed to narrow down the problem and I would provide the test project to reproduce it later.

from altcover.

The process is limited by the file I/O both during the test running and again during the post-processing (somewhere around 50k visits processed per second in each phase), and this dominates the process. There is a possible space/time trade-off in switching off the compression, but doing so would lead to the equivalent of coverlet issue #70; however experiments to push the data uncompressed to a separate process (e.g. by sending the serialized records as UDP packets) did not increase the throughput -- there were unacceptable levels of packet loss unless the throughput dropped below the rate that simply buffering to file gives.

At this point, I suspect that this one is a "can't fix".

from altcover.

Finally, I found the bottleneck. Release 3.5.543 has the change, and the major speed-up I'd been looking for while tinkering with the I/O.

from altcover.

Closing, assumed sufficiently improved.

from altcover.