Open
Bug 1487319
Opened 6 years ago
Updated 2 years ago
Measure where a code coverage build is spending time
Categories
(Testing :: Code Coverage, enhancement)
Testing
Code Coverage
Tracking
(Not tracked)
NEW
People
(Reporter: marco, Unassigned)
References
(Blocks 1 open bug)
Details
We should measure what are the parts that are slowest in coverage builds, to see what are the first things we should optimize.
Calixte started this work by analyzing xpcshell tests and comparing them between a normal build and a coverage build. The slowest part seemed to be the I/O to write/merge GCDA files.
The overhead of writing/merging GCDA files might be smaller in other test suites that don't launch so many processes in parallel, so we should make sure the finding applies to other suites as well (e.g. wpt or mochitest).
P.S.: There's a possibility that at some point mochitest will be run in parallel too (bug 1419135), but who knows if/when that's going to happen.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•