Xdebug's Code Coverage speedup
Besides a debugging and development aid, Xdebug also implements the back-end code to provide code coverage information for use with PHPUnit. Code coverage tells you how much of your code base is actually being tested by your unit tests. It's a very useful feature, but sadly, it slows down PHP's execution quite a lot. One part of this slowdown is the overhead to record the information internally, but another part is because I have to overload lots of opcodes. (Opcodes are PHP's internal execution units, similar to assembler instructions) They are always overloaded even if code coverage is not used, because it's only safe to overload them for the whole request.
The upcoming Xdebug 2.2 has a few changes to improve code coverage performance. First of all, the speed with which information about code coverage is recorded has been improved by contributions by Taavi Burns. And secondly, Xdebug 2.2 features a new setting, xdebug.coverage_enable with which it is possible to disable the overloading of code coverage specific opcodes. By default that setting will still be on.
Just to show how those improvements have effect on the speed, I've run a benchmark (running Apache Zeta Components Graph's tests) to compare Xdebug 2.1.2 against Xdebug 2.2-dev.
The results are as follows:
|
Version |
With CC |
Without CC |
With coverage_enable=0 |
Without Xdebug |
|
2.1.2 |
06:44 |
00:49 |
not available |
00:32 |
|
2.2-dev |
05:37 |
00:48 |
00:46 |
00:32 |
Another benchmark, run by Ross McFarlane gives: @derickr Based on 3 runs each, execution of 254 tests with 1070 assertions has dropped from 19s to 12s. Nice work!.
In Xdebug 2.2 I would also like to introduce modes. Each mode will set a default configuration for Xdebug's setting to be the most optimal for that specific tasks. Examples of tasks could be: "profiling", "debugging" or "tracing". Let me know (in the comments) whether you think that's a good idea.
Comments
I love the idea of Modes.
At present my workplace is looking to switch on XDebug on a production (but low-traffic) server to help identify areas of dead code. We don't have full unit-test coverage, so this would go some way to help turn these up.
Being able to use a lightweight mode that just showed details like method calls would be great for this.
Very nice improvement. Is there any plan to enable code coverage only for a file or a set of files ?
Is there any plan to enable code coverage only for a file or a set of files ? — mageekguy
This is already possible as you need to start and stop code coverage with xdebug_start_code_coverage() and xdebug_stop_code_coverage(). Only the files that are included and functions that are executed when code coverage collection is active will then be part of the returned data.
I know that, but with this solution, the result is the code coverage of all files included during execution, and not only a specific file. I think that it must be interesting to have xdebug_start_code_coverage('/path/to/class/file') to get the code coverage only for this file.
Nice work and sounds like a neat idea! :)
Life Line
Created 2 benches
I hiked 11.3km in 3h31m08s
Updated a pub
Updated a pub
Updated 4 pubs; Confirmed a pub
Created a restaurant
I walked 0.8km in 9m31s
I walked 2.1km in 16m42s
I walked 4.7km in 48m42s
I walked 7.4km in 1h16m10s
Updated a fast_food
Updated a cafe, a pet shop, and a bench; Confirmed a cafe, a convenience shop, and a motorcycle_repair shop
I walked 5.0km in 1h2m27s
I walked 1.1km in 10m08s
Updated a cafe; Confirmed 3 convenience shops, a fast_food, and a laundry shop
Created a fitness_centre; Updated an event_caterer office and a social_facility; Confirmed a restaurant and a pharmacy
I walked 7.6km in 1h29m58s
Updated a pub
I walked 10.8km in 2h18m39s
Created 3 entrances
I walked 6.5km in 1h8m25s
Created 2 fast_foods, a convenience shop, and 2 other objects
I hiked 10.6km in 2h59m33s
I walked 3.2km in 1h17m20s
I walked 3.3km in 1h2m23s

Shortlink
This article has a short URL available: https://drck.me/xdebug-cc-speed-8s9