For details, see this GitHub commit, a new change that composer just introduced:
https://github.com/composer/composer/commit/ac676f47f7bbc619678a29deae097b6b0710b799
The change is to use the gc_disable()
function (PHP 5.3+) to turn off PHP's cyclic reference collector before calculating dependencies.
The test in the comment area shows that the efficiency of this change is enormous (246s->100s, 196->104s,138->26s, etc.).
What is the underlying reason for this phenomenon?
Reply content:
For details, see this GitHub commit, a new change that composer just introduced:
https://github.com/composer/composer/commit/ac676f47f7bbc619678a29deae097b6b0710b799
The change is to use the gc_disable()
function (PHP 5.3+) to turn off PHP's cyclic reference collector before calculating dependencies.
The test in the comment area shows that the efficiency of this change is enormous (246s->100s, 196->104s,138->26s, etc.).
What is the underlying reason for this phenomenon?
This example has been included in the manual.
http://php.net/manual/zh/function.gc-disable.php
Can is 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 creates a large number of objects at run time that trigger the GC mechanism, which needs to be used, so the GC cannot be purged, so it saves CPU time and is more efficient when GC is disabled using gc_disable.
Reddit commented that since PHP's GC is based on reference counting, in order to be able to reclaim objects that are referenced in a circular reference, when ref count is reduced but less than 0, an attempt is made to detect and reclaim a circular referenced island object. However, when the number of valid objects and the reference to each other is large (for example, composer in the package, version and mutual dependencies), the cost of this search becomes very large, resulting in a lot of CPU computation
Compiler with GC will slow down because the heap is traversed to recycle garbage.