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! :)
Shortlink
This article has a short URL available: https://drck.me/xdebug-cc-speed-8s9