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 a vending_machine
Updated a bus_stop
I hiked 5.4km in 2h35m46s
I walked 2.2km in 27m13s
I walked 1.6km in 32m29s
I walked 3.3km in 34m33s
Updated a confectionery shop, a massage shop, and 2 other objects; Deleted a books shop
I hiked 7.0km in 4h21m00s
Updated a deli shop and a pet_grooming shop
I walked 4.2km in 49m42s
I walked 1.4km in 10m14s
I walked 2.2km in 1h43m13s
I walked 4.4km in 1h25m00s
Updated a cafe
Updated a bar
I walked 1.7km in 19m07s
I got a new lens. It's a little bit larger, and loads heavier, than my older one.
I walked 1.6km in 15m10s
Updated a pub
I walked 4.5km in 41m34s
Merge branch 'v2022'
Merge branch 'isspace-fixes' into v2022
Cast to 'unsigned char' for all ctype style functions (isspace, toupp…
I saw a Kingfisher fishing yesterday!
It's not a great photo, but it was great seeing it using the branch as a perch for fishing.




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