In his latest post Anthony Ferrara looks at a recent change in the Composer dependency management tool involving a major speed boost, just from disabling the garbage collection.

If you've been following the news, you'll have noticed that yesterday Composer got a bit of a speed boost. And by "bit of a speed boost", we're talking between 50% and 90% speed increase depending on the complexity of the dependencies. But how did the fix work? And should you make the same sort of change to your projects? For those of you who want the TL/DR answer: the answer is no you shouldn't.

He talks about what the actual (one line) change was that sped things up but goes on to talk about why doing this isn't necessarily a good thing. He covers how PHP handles variables internally, how it relates to "pointers" and the copy-on-write functionality. He includes code snippets and gives an overview of how each would be handled by the interpreter. Unfortunately, the way PHP handles things, deleting a variable only removes variable reference, not the value, but does decrement the reference count for it. When that hits 0, garbage collection kicks in and removes associated values too.

He talks about a few other kinds of garbage collection (the reference count method is just one of them) and circles back around to how this relates to Composer's functionality. He points out the number of objects created during the dependency resolution process and what can happen when the root buffer, populated with all of these objects, gets too full (hint: garbage collection). He finishes the post talking about how, in Composer's case, the garbage collection change yielded the performance impact it did, but doesn't suggest it for every project. He also makes a few suggestions as to things that could be done to improve PHP's garbage collection handling.