Slow composer dependency dependencies despite -prefer-dist flag

Question

Why do my composer's dependency updates take up to two minutes, even if there were no changes?

A popular suggestion is to add the --prefer-dist flag, which I --prefer-dist to my command:

 php composer.phar update --prefer-dist 

But it does not matter. Below is my composer.json file - am I missing something?

 { "name": "my-namespace/symfony", "type": "project", "description": "", "require": { "php": ">=5.3.3", "symfony/symfony": "2.3.*", "doctrine/orm": ">=2.2.3,<2.4-dev", "doctrine/doctrine-bundle": "1.2.*", "twig/extensions": "1.0.*", "symfony/assetic-bundle": "2.3.*", "symfony/monolog-bundle": "2.3.*", "sensio/framework-extra-bundle": "2.3.*", "sensio/generator-bundle": "2.3.*", "sensio/distribution-bundle": "2.2.*", "my-namespace/my-bundle": "1.0.*" }, "repositories": [ { "type": "vcs", "url": "http://username:[e-mail]/my-bundle.git" } ], "scripts": { "post-install-cmd": [ "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap", "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache", "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets", "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile" ], "post-update-cmd": [ "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap", "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache", "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets", "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile" ] }, "config": { "bin-dir": "bin" }, "minimum-stability": "dev", "extra": { "symfony-app-dir": "app", "symfony-web-dir": "web", "branch-alias": { "dev-master": "2.3-dev" } } } 

Answer 1

This issue is often related to loading xdebug in your CLI. (It doesn't matter if xdebug is enabled or not.)

You can check if xdebug is enabled using one of the following commands.

 // Unix php -m | grep xdebug // Windows php -m | findstr xdebug 

Additional information about which operations take so long can be obtained by providing maximum detail and profiling of information. (Replace install with update if you are updating packages.)

 composer install --prefer-dist -vvv --profile 

Answer 2

Factors that can slow down the composer:

• As indicated, xdebug can affect Composer performance. Running composer diagnose also warn you about this.

• Running update instead of install . Too often people just run update constantly. This forces Composer to go through the entire process of resolving dependencies, regardless of whether it has changed or not. When you run install , Composer takes the requirements directly from your .lock file, skipping the dependency resolution process. You should only run update during the development life cycle of your application. And even then, this is not something you usually have to do daily.

• If you have a specific dependency that you often update yourself, try simplifying the process by running composer update vendor/package --with-dependencies .

• Setting minimum-stability to dev . This greatly expands the scope of capabilities that the dependency resolver must consider. You should almost never lower minimum-stability to dev unless you have another choice. See alternatives, for example, temporarily using the @dev built-in flag.

Answer 3

It looks like the problem is resolved, but it might help someone.

Whenever I started installing or updating the composer, it took more than 10 seconds to extract the file https://packagist.org/packages.json . In the end, I found out that the problem is related to IPv6, as it took less than a second to fetch files from IPv4 sites.
The problem is that my ISP does not support IPv6, but I have included it in my ethernet properties. After I disabled Internet Protocol Version 6 (TCP/IPv6) in my network settings, the installation / update speed improved significantly (dropped from 200 + seconds to 10)

Answer 4

I had this problem while running Symfony2 on a low memory virtual machine. I increased the memory of the machine, and it improved significantly. You can check the memory in your system and see if it can be updated.

Answer 5

You are using a private repository. This will not allow you to download the compressed version of the version that you include, but should clone the repository. In addition, it is possible that the entire repository needs to be scanned to find the correct version.

You should check if using Satis is an option. Thus, you can create ZIP files of your own software and upload them in the same way as things hosted on Github (which has an API for this, which Composer uses to download ZIP files, even if they are not explicitly prepared).

Answer 6

Indeed, xdebug will certainly slow down. However, removing xdebug is not ideal. A good option is to use HHVM and put it on the composer's work.

Installing HHVM is pretty painless, and HHVM itself is much faster than PHP5. This is a double victory - YMMV, but I got an almost 5-fold increase in speed (on a sofa with an eye core, admittedly) in using the composer, which I would get even if xdebug was not in the picture.

If you are on OS X, this link may help (blog post I wrote on this subject):

http://circlical.com/blog/2015/11/11/slow-composer-on-os-x

Answer 7

I had the same problem with composer update , I updated the composer to the latest version using composer selfupdate update the composer, and now its speed is acceptable.

Answer 8

Check if zip and unzip installed. If they are missing, Composer will clone the repository instead of downloading the compressed release.

Answer 9

I added priordence :: ffff: 0: 0/96 100 to the /etc/gai.conf file and tried your upgrade.