为什么禁用垃圾回收(GC)会给composer带来巨大的运行效率提升？

具体请看这个GitHub commit，这是composer刚刚引入的一个新改动：

https://github.com/composer/composer/commit/ac676f47f7bbc619678a29deae097b6b0710b799

其改动内容是用gc_disable()函数（PHP 5.3+）在计算依赖关系前把php的循环引用收集器关掉。

评论区的测试表明这个改动的效率提升是非常巨大的（246s->100s、196->104s，138->26s等）。

请问造成这个现象的内在理由是什么？

回复内容：

具体请看这个GitHub commit，这是composer刚刚引入的一个新改动：

https://github.com/composer/composer/commit/ac676f47f7bbc619678a29deae097b6b0710b799

其改动内容是用gc_disable()函数（PHP 5.3+）在计算依赖关系前把php的循环引用收集器关掉。

评论区的测试表明这个改动的效率提升是非常巨大的（246s->100s、196->104s，138->26s等）。

请问造成这个现象的内在理由是什么？

手册上已经收录了这个例子了。

http://php.net/manual/zh/function.gc-disable.php

Can be very useful for big projects, when you create a lot of objects that should stay in memory. So GC can't clean them up and just wasting CPU time.

composer在运行的时候会创建大量的对象，这些对象会触发GC机制，而这些对象需要被使用，所以GC无法清除，因此，使用gc_disable禁用GC之后，会节省cpu时间，效率更高。

Reddit上有评论指出，由于PHP的GC是基于引用计数的，为了能够回收循环引用的对象，会在ref count减少但不到0的时候，试图检测并回收循环引用的孤岛对象，但当有效对象的数量及互相引用较大（比如composer中代表包、版本和互相的依赖关系）的时候，这种搜索的开销就会变得非常巨大，造成大量的CPU计算

有gc的compiler都会使运行速度变慢，因为得遍历heap来回收垃圾