Live data from Hacker News

Composer – Disable GC when computing deps and refs

github.com

111–120 of 135 posts

Re: Composer – Disable GC when computing deps and refs

#111
post #55

For those looking for a technical explanation, the PHP garbage collector in this case is probably wasting a ton of CPU cycles trying to collect thousands of objects (a LOT of objects are created to represent all the inter-package rules when solving dependencies) during the solving process. It keeps trying and trying as objects are allocated and it can not collect anything but still has to check them all every time it…

Out of curiosity what tools do you use for profiling and finding these sorts of things? Plain old xdebug, xhprof, or other things? I'm going to have to jump into debugging a fairly large Symfony application within the next couple months and am on the look out for good tools to help me along.

Traditionally xdebug/xhprof were pretty decent, but xhprof has been a bit abandoned since facebook uses HHVM now.

There are two new commercial condenters though that came out in the last few months: Blackfire.io and QafooLabs.com

Both have announced support for showing GC time in profiles as a result of today's noise :) https://twitter.com/beberlei/status/539816149303955456 https://twitter.com/symfony_en/status/539815082881187841

Re: Composer – Disable GC when computing deps and refs

#112

Earlier quoted context omitted.

It's much closer to reddit than 4chan, otherwise the nature of the images posted would be a little different. And it's been like this for 2 or 3 years now. I've seen comment spam of images for commits and issues for quite a while.

The first one I remember was the commit that added CoffeeScript to rails by default. https://github.com/rails/rails/compare/9333ca7...23aa7da

The first I remember was https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/commi... , but I guess that was a couple of months later.

Re: Composer – Disable GC when computing deps and refs

#113
post #81

Earlier quoted context omitted.

> Also, memory nowadays is cheap, CPU power isn't. Unless you're running your deployment on a 512Mb or 1G VM. I've had composer max out swap on those too. Even with 2G RAM it's not been happy sometimes, so be interesting to see what difference this patch makes.

Yeah, i have had to move to more expensive ec2 instance on account of this very issue..

IMO you should commit your composer.lock file up to your repository and then use composer.phar install --no-dev --optimize-autoloader on any production instance. Install is much faster and uses hardly any memory compared to the update command.

To add/update any dependencies for your project run the composer.phar update on your development environment or somewhere it can use a ton of memory and cpu without issue. Then just commit and push up your composer.lock changes. Been doing it this way for over a year and had no issues deploying changes in ec2.

Re: Composer – Disable GC when computing deps and refs

#115

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?

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…

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.

Re: Composer – Disable GC when computing deps and refs

#118
post #81

Earlier quoted context omitted.

This; interpreting performance numbers is hard. Also, memory nowadays is cheap, CPU power isn't.

> Also, memory nowadays is cheap, CPU power isn't. Unless you're running your deployment on a 512Mb or 1G VM. I've had composer max out swap on those too. Even with 2G RAM it's not been happy sometimes, so be interesting to see what difference this patch makes.

You shouldn't be running composer update on your deployment, just composer install which doesn't take as much memory since it doesn't have to resolve dependencies.

Re: Composer – Disable GC when computing deps and refs

#119
post #81

Earlier quoted context omitted.

This; interpreting performance numbers is hard. Also, memory nowadays is cheap, CPU power isn't.

> Also, memory nowadays is cheap, CPU power isn't. Unless you're running your deployment on a 512Mb or 1G VM. I've had composer max out swap on those too. Even with 2G RAM it's not been happy sometimes, so be interesting to see what difference this patch makes.

> Unless you're running your deployment on a 512Mb or 1G VM.

Question - why not run Composer locally, as part of deployment?

Re: Composer – Disable GC when computing deps and refs

#120

The commit is great. I love that the comments have spiraled completely out of control. At this point, 30 minutes after the link was posted, the comment thread is now a competition to see who can post the best gif. I know we're serious here, but stuff like this reminds me why I love the internet so much. It's fun to cut loose once in a while.

pictures/gifs don't belong in github comments. this is the dumbest thing.
Post reply on HN