Page MenuHomePhabricator

Add pcov PHP extension to wikimedia apt so it can be used in Wikimedia CI
Open, MediumPublic

Event Timeline

Alternatively we could do a hack like we do for sury-php?

Alternatively we could do a hack like we do for sury-php?

Honestly, I have no idea what the hack for sury is :) Anyway, I guess it would be fine, as long as we can pull an up-to-date version of pcov.

Alternatively we could do a hack like we do for sury-php?

Honestly, I have no idea what the hack for sury is :) Anyway, I guess it would be fine, as long as we can pull an up-to-date version of pcov.

Sorry for being gnomic! :-)

For sury-php, we just inject the personal nightly PHP packages that sury makes before they get properly packaged for debian, and so can use versions which aren't approved for each Debian release: https://gerrit.wikimedia.org/r/plugins/gitiles/integration/config/+/master/dockerfiles/sury-php/Dockerfile.template

Gotcha, thanks! I'll leave that up for you to decide, as I'm not qualified for that. My only thought is that, as long as the solution is reusable, it's fine. I'm specifically thinking about the possible use case in vagrant (somewhat related to T244716).

Alternatively, can we pull pcov from git and compile as per https://github.com/krakjoe/pcov/blob/develop/INSTALL.md#installation ?

hashar closed this task as Declined.Apr 1 2020, 6:06 PM

The incentive was to benefit from speed improvement. We got Xdebug main slowness identified and solved T234418. phpcov coverage is also slightly different.

Daimona reopened this task as Open.Apr 1 2020, 6:19 PM

The incentive was to benefit from speed improvement. We got Xdebug main slowness identified and solved T234418.

While that might have been a slowness cause, it's still insufficient. First of all, we're using xdebug 2.7.*, but 2.9.0 claims a 250% speed up compared to 2.7.0. At least, this is something that could be explored. Second, pcov is still way faster than xdebug 2.9.*, based on local tests; see T234020#5826901 for an example. If the improvement is really that big, it would be foolish not to take advantage of a relatively easy change like switching the coverage driver.

IMHO, we cannot decline this task because "xdebug is already faster" without knowing first how much pcov can be faster than xdebug.

phpcov coverage is also slightly different.

It is, but is that a problem? As I wrote in T234020#5826901, the only notable differences are that pcov ignores lines with a global declaration (i.e. global $wgFoo), and the first line of switch expressions (i.e. switch ( $foo )). Is it bad not to have these lines show up as coverable? IMHO, no. Especially if that comes with a noticeable performance improvement.

jbond triaged this task as Medium priority.Jun 15 2020, 10:11 AM
jijiki moved this task from Incoming 🐫 to Unsorted on the serviceops board.Aug 17 2020, 11:46 PM

Memo (for myself or whoever is interested): xdebug 3 should supposedly bring massive performance improvements. Copying from the release notes for 3.0.0beta1:

This made it possible to massively increase performance in many of Xdebug's sub systems as Xdebug is now much more conservative in which hooks are enabled.

Configuration changes, massive performance improvements, and PHP 8 support are the primary features in Xdebug 3

Once a stable is version is released, we should check its performance compared to pcov. If it turns out to be similar or better, we might consider staying with xdebug, as long as we upgrade it to version 3. Note, IMHO it's still subpar to use an "all-in-one" debugger for coverage (because dedicated coverage drivers like pcov or phpdbg should in principle be faster), but I guess upgrading xdebug would be easier, thus acceptable (at least temporarily).