Hacker News Reader

Comment by Mithaldu | Hacker News Reader

As far as i understand composer is roughly the same thing as the cpan client. And they just simply disabled the garbage collector for it.

What is this guy doing that he needs gigabytes of memory to install a bunch of php libraries?

    Before: Memory usage: 2194.78MB (peak: 3077.39MB), time: 1324.69s
    After:  Memory usage: 4542.54MB (peak: 4856.12MB), time:  232.66s

View on HN

That user is using PEAR, which is the old shitty PHP "CPAN"

That's the reason for the huge memory usage. We're slowly moving away from PEAR, but since it works for now not everyone has/will transition.

Edit: I should also point out that there are a few packages that almost everyone uses (PHPMD, PHPCS, phpUnit) that are still mostly pulled from PEAR, though I think phpUnit has a composer option.

PHPUnit stopped updating PEAR in April, and actively destroyed PHPUnit on their PEAR repo at the start of this month (i.e. a patch version update that consisted just of a bash script printing a migration message...).

Recursively gathering all dependencies a project might have. A huge downside of the modern scripting languages landscape is that dependency graphs can get quite convoluted

So, did they exchange a 70% reduction in execution time for a 100% increment in memory usage?

In that particular case; other reports on that thread show much better reductions in time for much lower increases in memory.

1324 -> 232. If you say 70% reduction VS 100% increment sounds like you are talking the same stuff and it is possible to compare 70 with 100.

The reality is even in the above edge case: 2x memory, 6x speed.

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.

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.

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.

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

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

Yeah, seems like a bug "fix."

The jubilation in the comments over this seems... misplaced?

Yeah, I wondered when They turn it on again.

Reply on news.ycombinator.com