View Issue Details

IDProjectCategoryView StatusLast Update
0001208XdebugUncategorizedpublic2020-03-12 17:01
ReporterSeldaek Assigned Toderick  
PriorityhighSeverityfeatureReproducibilityhave not tried
Status resolvedResolutionwon't fix 
Product Version2.3.3 
Summary0001208: Look at optimisations for Xdebug - especially in combination with composer.

I 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 Reproduce

git clone
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



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
cd monolog
composer update --dry-run --profile --no-dev
composer update --dry-run --profile --no-dev


2016-11-26 21:13

reporter   ~0003793

Last edited: 2016-11-26 21:15


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.


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


2016-12-12 00:10

administrator   ~0004025

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


2016-12-12 10:31

reporter   ~0004035

In Composer 1.3 we added 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
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
2020-03-12 16:55 derick Severity major => feature
2020-03-12 17:01 derick Category Feature/Change request => Uncategorized