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
Confirmed a fast_food
Updated a bench
Updated a bench
I walked 5.3km in 1h2m15s
Updated a community_centre
I walked 8.7km in 1h52m18s
I walked 0.8km in 9m36s
Created an office
I walked 10.0km in 3h10m10s
I walked 0.8km in 10m14s
Updated a pub
Updated a restaurant; Confirmed a studio
I walked 1.6km in 19m27s
I walked 4.2km in 46m45s
I walked 1.7km in 16m23s
Created 9 picnic_tables, 2 pitches, and a bench; Updated 5 benches; Deleted a pitch
I walked 5.8km in 1h9m48s
I had this lovely Robin posing for me on my walk last weekend.
#BirdPhotogaphy #BirdsOfMastodon #Birds #photography #NorthDowns
Updated 6 benches
I walked 10.7km in 1h47m17s
Updates from walk
Created a waste_basket, an information, and a grit_bin; Updated 2 bicycle_parkings
Created 8 waste_baskets; Updated 3 benches and 3 waste_baskets
I walked 7.0km in 1h29m40s



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