[Maken]

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

[antirez]

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.

[Cthulhu_]

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

[porker]

> 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.

[andrewryno]

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.

[vertex-four]

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

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

[jayzalowitz]

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

[sneakest]

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.

[icebraining]

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