View Issue Details

IDProjectCategoryView StatusLast Update
0001208XdebugFeature/Change requestpublic2016-12-12 10:31
ReporterSeldaekAssigned Toderick 
PriorityhighSeveritymajorReproducibilityhave not tried
Status resolvedResolutionwon't fix 
Product Version2.3.3 
Target VersionFixed in Version 
Summary0001208: Look at optimisations for Xdebug - especially in combination with composer.
DescriptionI am trying to disable xdebug programmatically in Composer because having the extension loaded makes a Composer run 4x slower which is quite bad. ini_set('xdebug.default_enable', 0); does not seem to change anything though.
Steps To Reproducegit clone https://github.com/composer/packagist
cd packagist
composer update --dry-run --profile
composer update --dry-run --profile

Do it twice as the first one will prime the composer cache, second time should almost only be CPU-bound.

Then disable xdebug ext entirely, and run again, for me it's 4x faster (80s => 20s)
TagsNo tags attached.
Operating System
PHP Version5.6.0-5.6.4

Activities

Seldaek

2015-11-17 14:52

reporter   ~0003229

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

lkraav

2016-11-26 21:13

reporter   ~0003793

Last edited: 2016-11-26 21:15

View 2 revisions

(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"?

derick

2016-12-12 00:10

administrator   ~0004025

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

Seldaek

2016-12-12 10:31

reporter   ~0004035

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.

Issue History

Date Modified Username Field Change
2015-11-17 13:26 Seldaek New Issue
2015-11-17 14:52 Seldaek Note Added: 0003229
2015-11-20 17:44 derick Target Version => 2.5.0dev
2015-11-20 17:44 derick Summary Disabling xdebug.default_enable has no effect on performance => Look at optimisations for Xdebug - especially in combination with composer.
2016-11-26 21:13 lkraav Note Added: 0003793
2016-11-26 21:15 lkraav Note Edited: 0003793 View Revisions
2016-12-04 18:34 derick Target Version 2.5.0dev =>
2016-12-12 00:10 derick Note Added: 0004025
2016-12-12 00:10 derick Status new => resolved
2016-12-12 00:10 derick Resolution open => won't fix
2016-12-12 00:10 derick Assigned To => derick
2016-12-12 10:31 Seldaek Note Added: 0004035