Comments (6)
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.
Related Issues (20)
- [enhancement] integration with xharness and/or device runners for iOS and Android HOT 2
- `dotnet test /p:AltCover=true /p:AltCoverInPlace=true` results in System.IO.IOException: The process cannot access the file 'C:\src\testprj\bin\Debug\net8.0\AltCover.Recorder.g.dll' because it is being used by another process. HOT 5
- help with getting started HOT 2
- Path.GetFullPath no longer resolves long file paths HOT 7
- Could not find coverage.xml.zip when running Instrumented binaries HOT 5
- Adding AltCover to projects results in dotnet test running against all projects in solution HOT 6
- Running AltCover Runner in parallel mode HOT 2
- Question about cyclomatic complexity for pattern match HOT 2
- Changes so AltCover will run when FIPS compliance is required HOT 13
- .../Temp/tmp###.altcover.runsettings not found Intermittent tests ignored. HOT 2
- BranchPoints differ between .NET Framework and .NET 7 when using interpolated strings HOT 5
- Question Regarding assemblies being added to code coverage result HOT 2
- Command vstest.console.exe not started. Why? HOT 3
- altcover runner --OutputFile gives incorrect summary output HOT 8
- ERROR *** Instrumentation phase failed - Failed to resolve assembly: System.Data.Common HOT 8
- Generic methods share the same name and signature HOT 5
- Collection phase failed with an Error HOT 9
- Per-test level code coverage HOT 2
- Coverage collection requires instrumented code in same location until collection is not completed causing service downtime HOT 4
- Question : Codecov says braces are not covered HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from altcover.