Yet another JS code coverage tool that computes statement, line, function and branch coverage with module loader hooks to transparently add coverage when running tests. Supports all JS coverage use cases including unit tests, server side functional tests and browser tests. Built for scale.
Other
8.7k
stars
786
forks
source link
speedup of report generation for large projects #612
I’m working on a project where I’m using istanbul report to generate a single report from ~1500 coverage output files, and… it was a bit slow for my taste. :snail:
These commits brought down the time for generating the output from an impressive 5m37s to “just” 1m44s. You can happily turn this PR down, but I’d have felt bad not providing you with these patches.
If this further annoys me and you’re interested, I might write up a patch that spreads up coverage file merging among several worker processes – it seems running JSON.parse on the coverage files is where almost all of the time is spent after this, and while that is not easily optimized, it’s certainly parallelizable.
Edit: Tests are failing, but also locally for me without any changes (Node.js v6, x64 Linux). So, take a look when you have the time.
@lo1tuma Updated with a slower but more generic approach that does a full deep clone on the input objects. It’s still a significant ca. 2× speedup over the previous JSON round-trips.
Coverage decreased (-0.2%) to 97.274% when pulling cb72691427e66ae899875daf98a4229260ff1c93 on addaleax:report-performance into 0e8c3503d9e1c50e3a446f94e1429ceb1bd7fda0 on gotwarlost:master.
Hi there!
I’m working on a project where I’m using
istanbul report
to generate a single report from ~1500 coverage output files, and… it was a bit slow for my taste. :snail:These commits brought down the time for generating the output from an impressive 5m37s to “just” 1m44s. You can happily turn this PR down, but I’d have felt bad not providing you with these patches.
If this further annoys me and you’re interested, I might write up a patch that spreads up coverage file merging among several worker processes – it seems running
JSON.parse
on the coverage files is where almost all of the time is spent after this, and while that is not easily optimized, it’s certainly parallelizable.Edit: Tests are failing, but also locally for me without any changes (Node.js v6, x64 Linux). So, take a look when you have the time.