要明白是什么影響了Composer的運行速度，必須先理解Composer的運行原理。Composer的大致運行步驟如下：

分析你的composer.json文件，找到所有需要安裝的第三方的名稱和對應的版本號

2.從本地緩存目錄和Packagist服務器獲取上述的第三方的信息，包含最新版本，代碼存放等等

3.分析依賴關系，根據包依賴、版本是否有更新等條件計算出最終需要安裝的第三方的清單

4.根據這份清單第三方的源代碼，根據參數的不同，方式會是用Git Clone項目或者是直接Zip包

5.將第三方安裝到本地，一般是安裝在項目下的./vendor目錄，同時根據參數生成用于載入第三方的autoload文件

分析：從上述步驟中可以看到Composer在運行時會有5個不同的階段，而其中1、2、3、4步都是會因為各種原因導致Composer執行速度緩慢的，類似composer-proxy這樣的Composer鏡像/代理站其實已經解決了第1、2步驟速度慢的問題，也就是加快從Packagist版本更新定義文件慢的這一步。而3這一步由于PHP的運行效率所限制，加上計算依賴的算法又特別復雜，所以如果用的第三方特別多，就特別容易造成內存不足、超時、運行緩慢等問題。

測試基于6個項目進行composer update --dry-run得出，可以看到使用了HHVM之后速度從2分14秒提高到了34秒，平均6秒就完成一個項目的composer update，可見速度提升是非常大的。