4 ms·

Could someone more versed with PHP, and this project explain why turning off garbage collection helped so much? and why they didn't turn it back on at the end o

Could someone more versed with PHP, and this project explain why turning off garbage collection helped so much? and why they didn't turn it back on at the end of the function?

daveid 12y ago
Garbage collection is slow, but reduces memory usage. So disabling it costs memory. Also, Composer does not keep running, once the job is done, the script terminates, so you don't have to enable GC back again (it's only disabled in the context of the current execution).
- masklinn 12y ago
  > Garbage collection is slow, but reduces memory usage Note that it's only reducing memory usage if there are cycles. The rest will be collected when the refcount falls to 0.
jcampbell1 12y ago
PHP is reference counted, so memory is typically freed as soon as an object is no longer needed. Cycles are the exception which can cause memory leaks, so in version 5.3 php added a cycle collector, which reads every object in memory and very occasionally deletes objects that are disconnected and have greater than zero reference counts (cycles). In my opinion, the php cycle collector is a pointless waste of time. In objective-c, apple just let's the memory leak by default, and they give you tools to find the leaks, and then you modify the code to break the cycles. There is no need to turn cycle collection back on at the end of the program, because OS frees the memory at program termination.
- innocenat 12y ago
  I agree that cycle collector is pointless waste of time. Most script runs short enough that the memory leak doesn't really matter. But for long running script, it's either cycle collector, or add support for weak reference. But IMO, due to how reference are stored in PHP, and to my limited knowledge of PHP core, I am quite sure cycle collector are more beneficial in both developer time and usefulness. (Not every programmers know how to manage reference cycle)
- vertex-four 12y ago
  I'll note that in common usage, PHP does not exit entirely at the end of every HTTP request. (By default, PHP-FPM never exits between requests.) You would, at the least, have to keep track of all live objects and delete them at the end of each request... which sounds like a garbage collector to me.
Usu 12y ago
Turning it on again it's currently being discussed: https://github.com/composer/composer/issues/3488 https://github.com/composer/composer/issues/3488
masklinn 12y ago
> Could someone more versed with PHP, and this project explain why turning off garbage collection helped so much? The cycle collector is relatively recent, I expect it's not very performant (since most PHP applications don't need it) and composer's dependency resolution may be hitting a pathological case (create lots of objects without cycles, triggering lots of collections but no actually useful work) > and why they didn't turn it back on at the end of the function? Since it's a package manager, I'd guess the expectation is the process will die soon-ish afterwards (once it's installed whatever it's resolved). There's a discussion of re-enabling it after dependency resolution (so postinstall hooks run with GC enabled) though.

Could someone more versed with PHP, and this project explain why turning off garbage collection helped so much? and why they didn't turn it back on at the end of the function?

daveid 12y ago

Garbage collection is slow, but reduces memory usage. So disabling it costs memory. Also, Composer does not keep running, once the job is done, the script terminates, so you don't have to enable GC back again (it's only disabled in the context of the current execution).

masklinn 12y ago
> Garbage collection is slow, but reduces memory usage Note that it's only reducing memory usage if there are cycles. The rest will be collected when the refcount falls to 0.

jcampbell1 12y ago

PHP is reference counted, so memory is typically freed as soon as an object is no longer needed. Cycles are the exception which can cause memory leaks, so in version 5.3 php added a cycle collector, which reads every object in memory and very occasionally deletes objects that are disconnected and have greater than zero reference counts (cycles). In my opinion, the php cycle collector is a pointless waste of time. In objective-c, apple just let's the memory leak by default, and they give you tools to find the leaks, and then you modify the code to break the cycles. There is no need to turn cycle collection back on at the end of the program, because OS frees the memory at program termination.

innocenat 12y ago
I agree that cycle collector is pointless waste of time. Most script runs short enough that the memory leak doesn't really matter. But for long running script, it's either cycle collector, or add support for weak reference. But IMO, due to how reference are stored in PHP, and to my limited knowledge of PHP core, I am quite sure cycle collector are more beneficial in both developer time and usefulness. (Not every programmers know how to manage reference cycle)
vertex-four 12y ago
I'll note that in common usage, PHP does not exit entirely at the end of every HTTP request. (By default, PHP-FPM never exits between requests.) You would, at the least, have to keep track of all live objects and delete them at the end of each request... which sounds like a garbage collector to me.

Usu 12y ago

Turning it on again it's currently being discussed: https://github.com/composer/composer/issues/3488 https://github.com/composer/composer/issues/3488

masklinn 12y ago

> Could someone more versed with PHP, and this project explain why turning off garbage collection helped so much? The cycle collector is relatively recent, I expect it's not very performant (since most PHP applications don't need it) and composer's dependency resolution may be hitting a pathological case (create lots of objects without cycles, triggering lots of collections but no actually useful work) > and why they didn't turn it back on at the end of the function? Since it's a package manager, I'd guess the expectation is the process will die soon-ish afterwards (once it's installed whatever it's resolved). There's a discussion of re-enabling it after dependency resolution (so postinstall hooks run with GC enabled) though.