3 ms·
Another major improvement to GCC9 is gcov - starting with GCC 9, gcov can spit out coverage results in JSON format as well as take multiple coverage files as ar
by umvi 8y ago
Another major improvement to GCC9 is gcov - starting with GCC 9, gcov can spit out coverage results in JSON format as well as take multiple coverage files as arguments, spitting out all the results to stdout, 1 json object per line (this is huge).
This will allow much of the code coverage calculation process to be done in parallel (i.e. much faster than is currently possible). This is because currently gcov writes everything out to files, which forces the wrapper to be single threaded lest one gcov process overwrite the output file of another.
For fun, I wrote a parallelized GCC9 gcov wrapper in python that generates an LCOV coverage report that genhtml can consume. Unofficial/anecdotal bench marking shows incredible gains over lcov on my own personal projects (700ms vs. 90 seconds). I'm sure it could be improved even more.
https://github.com/RPGillespie6/fastcov https://github.com/RPGillespie6/fastcov
- jcranmer 8y agolcov can be really, really slow in how it handles its own file format. I ended up rewriting the genhtml stuff myself in Python (originally, it was to drive a treemap view, but extending it to handle the actual detailed coverage wasn't difficult), and then moved the "merge two files into one file" into Python as well for a >10x speedup. And Python is not known for its blazing speed. After that, I ended up shifting to tackling the generation of the initial data from .gcda and .gcno, which is where I discovered bugs in both lcov and gcov in the collection process. One bug is that gcov somehow manages to compute negative edge counts on certain cycles in the graph, and when that happens, it double-counts those cycles.