Slow updating of composer dependencies, despite --prefer-dist flag
Why does it take up to two minutes for my composer dependencies to update, even when there have been no changes?
A popular suggestion is to append the --prefer-dist
flag:
php composer.phar update --prefer-dist
But this makes no difference in my case. Below is my composer.json file – am I missing something obvious?
{
"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:[email protected]/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"
}
}
}
This problem is often related to xdebug being loaded in your CLI environment. (It doesn't matter if xdebug is enabled or not.)
You can check whether xdebug is enabled using one of the followinc commands.
// Unix
php -m | grep xdebug
// Windows
php -m | findstr xdebug
Further information on what operations take so long can be gained by enabling maximum verbosity and profiling information. (Replace install with update if you are updating the packages.)
composer install --prefer-dist -vvv --profile
Factors that can slow down Composer:
As pointed out,
xdebug
can affect the performance of Composer. Runningcomposer diagnose
will also warn you about this.Running
update
instead ofinstall
. People too often just runupdate
constantly. This makes Composer go through the entire dependency resolving process, regardless of whether or not anything has changed. When you runinstall
, Composer takes the requirements directly from your .lock file, skipping the dependency resolving process. You should only runupdate
during the development lifecycle of your application. And even then, it's not something you have to run daily usually.If you have a specific dependency that you update frequently yourself, you could try simplifying the process by running
composer update vendor/package --with-dependencies
instead.Setting
minimum-stability
todev
. This greatly expands the amount of possibilities that the dependency resolver has to consider. You should almost never lower theminimum-stability
todev
unless you absolutely have no other choice. Look into alternatives, such as temporarily using a inline@dev
flag.
Seems like the problem was resolved, but this might help someone.
Whenever I ran composer install or update, it took more than 10 seconds just to fetch the https://packagist.org/packages.json file. Eventually I found out that the problem was related to IPv6, since fetching files from IPv4 sites took less than a second.
The problem is that my ISP doesn't support IPv6, but I had it enabled in my ethernet properties. After I unticked Internet Protocol Version 6 (TCP/IPv6)
in my network settings, install/update speeds drastically improved (dropped from 200+ seconds to like 10)
You are using a private repository. This will not allow to download zipped version of the version you include, but must clone the repository. Additionally, it might be that the whole repository must be scanned to find the required version.
You should check whether using Satis is an option. That way you could prepare ZIPs of your own software and download it just like the things hosted on Github (which has an API for this that is used by Composer to allow downloading ZIPs even if they are not explicitly prepared).
I was having this issue while running Symfony2 on a VM that had low memory. I increased the machine's memory and it improved drastically. You may check the memory on your system and see if it can be upgraded.