Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[3.4.0] Performance drop with composer/xdebug-handler 2.0.4 #6310

Closed
pacproduct opened this issue Feb 23, 2022 · 1 comment · Fixed by #6316
Closed

[3.4.0] Performance drop with composer/xdebug-handler 2.0.4 #6310

pacproduct opened this issue Feb 23, 2022 · 1 comment · Fixed by #6316
Labels

Comments

@pacproduct
Copy link

pacproduct commented Feb 23, 2022

Hi :)

Bug report

We're facing a surprising performance drop in our PHP CS Fixer CI routines since our last update of FriendsOfPHP/PHP-CS-Fixer to version 3.4 (as we're stuck on PHP 7.3 for now, with no way to upgrade to PHP 7.4+ or PHP 8+ unfortunately).

After further investigation, it seems like this is caused by composer/xdebug-handler 2.0.4 that came out the 4th of january 2022.

Tested with:

  • PHP 7.3
  • Composer 2.1
  • Git 2.20
  • PHP extension ext-pdo_sqlite (sudo apt install php7.3-sqlite)
  • PHP CS Fixer 3.4.0

Code snippet that reproduces the problem

Here is how to reproduce the performance drop caused by composer/xdebug-handler 2.0.4 on FriendsOfPHP/PHP-CS-Fixer 3.4.

Deploy a demo Symfony project:

git clone -b v1.8.0 --single-branch git@github.com:symfony/demo.git
cd demo
composer install

Install PHP CS Fixer the recommended way:

mkdir --parents tools/php-cs-fixer
composer require --working-dir=tools/php-cs-fixer friendsofphp/php-cs-fixer

SIDE NOTE

When writing these lines, at this stage composer/xdebug-handler 2.0.4 gets installed, which we believe is the version that causes the problem. If you end up with another version, the issue may or may not be still present.

Checked as follows:

composer show --working-dir=tools/php-cs-fixer composer/xdebug-handler

Resulting output:

name     : composer/xdebug-handler
[...]
versions : * 2.0.4
[...]

END OF SIDE NOTE

Run PHP CS Fixer with composer/xdebug-handler 2.0.4:

# Clear cache to be sure:
rm -f ./var/.php_cs.cache
# Run PHP CS Fixer:
tools/php-cs-fixer/vendor/bin/php-cs-fixer fix src

Resulting output:

Fixed all files in 16.637 seconds, 6.000 MB memory used

--> The run takes 16 seconds on my machine.

Run PHP CS Fixer with composer/xdebug-handler 2.0.3:

Downgrade composer/xdebug-handler to version 2.0.3:

composer require --dev --working-dir=tools/php-cs-fixer composer/xdebug-handler:2.0.3

Run PHP CS Fixer again:

# Clear cache:
rm -f ./var/.php_cs.cache
# Run PHP CS Fixer:
tools/php-cs-fixer/vendor/bin/php-cs-fixer fix src

Resulting output:

Fixed all files in 0.977 seconds, 14.000 MB memory used

--> The run takes roughly 1 second on my machine.

Our conclusion is that composer/xdebug-handler version 2.0.4 introduced a massive performance drop. On this example it goes from 1 second to 16 seconds which is still bearable, but on our real-size project, it bumped from a couple of minutes to almost half an hour!

We're planning on pinging the team maintaining composer/xdebug-handler too so they can have a look at this ticket for a way to reproduce the issue. EDIT: Done, see xdebug-handler#146.

Our current workaround is to enforce a downgrade to composer/xdebug-handler version 2.0.3 as shown above.

@SpacePossum
Copy link
Contributor

Thanks for all the digging and details reporting 👍 I'll follow the issue on the xdebug-handler repo, curious what is going on :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants