Faster way to reproduce (packagist is a bit of a large project to run profiling on really)

git clone https://github.com/Seldaek/monolog
cd monolog
composer update --dry-run --profile --no-dev
composer update --dry-run --profile --no-dev

(xdebug-2.4.1)

I'm fairly certain this isn't composer-specific. Just loading xdebug module on 7.0.13 causes page build speed to drop anywhere from 4x-8x. This is on WP, I'm using the industry standard Query Monitor plugin to get accurate performance data on each request. Test subject page, with apcu etc goodies, loads in 0.65s on average, over repeated reloads. As soon as xdebug is enabled, with all features turned OFF by default, page load time still jumps to 3.5-4.5s on average, over repeated reloads.

"xdebug.default_enable" seems to have no effect on this. Either it's a bug and xdebug for some reason doesn't even respect the variable correctly, or the base workload that xdebug has to do by just being enabled is massive.

PHP-FPM can't load a different zend_extension configuration across pools. This requires setting up a completely separate daemon instance. Inconvenient and messy, compared to simply toggling ini values via ".user.ini" and "SetEnv" for example.

SUMMARY

If xdebug would somehow manage to avoid this massive performance penalty in "xdebug.default_enable = 0" configuration state, that would be a huge step forward. Then it'd become possible to keep xdebug module always loaded, and toggle "xdebug.*" configuration values based on cookie/GET parameters (".user.ini" works well here).

I don't know, is this possible? Can xdebug completely unhook itself until "xdebug.default_enable = 1"?

This is a general "make it faster" report, that I can't do anything about.

In Composer 1.3 we added https://github.com/composer/composer/blob/master/src/Composer/XdebugHandler.php which does a lot of hackery with ini files to restart php without xdebug automatically, so the issue is resolved for us.