Composer: reduce memory consumption

[brusch]

At the moment it's necessary to raise Composer's memory limit to 3G in order to update/install Pimcore. This can cause major problems eg. on Windows systems with PHP compiled on x86 architecture (eg. XMAPP) and also in other environments.

It would be eligible that Pimcore runs with the default settings of Composer.

[brusch]

It seems that the main issues comes from

[340.1MB/16.54s] Downloading http://repo.packagist.org/p/symfony/lock%2410e792d68559e75c69797d202973bd896bf0e5ff5458d16357b24cb3c246bd11.json
[341.9MB/16.59s] Writing /home/bernie/.cache/composer/repo/https---repo.packagist.org/provider-symfony$lock.json into cache
[537.3MB/18.34s] Reading /home/bernie/.cache/composer/repo/https---repo.packagist.org/provider-symfony$propel1-bridge.json from cache
[1384.1MB/28.31s] Reading /home/bernie/.cache/composer/repo/https---repo.packagist.org/provider-rhumsaa$uuid.json from cache
[1390.7MB/28.36s] Reading /home/bernie/.cache/composer/repo/https---repo.packagist.org/provider-doctrine$phpcr-odm.json from cache
[1393.3MB/28.41s] Reading /home/bernie/.cache/composer/repo/https---repo.packagist.org/provider-guzzle$batch.json from cache

Currently I have no idea why the meta data for symfony/propel1-bridge is being downloaded and why it's taking such a huge amount of memory.

@Seldaek is there a way how I can further debug this? Thanks in advance!

[brusch]

It seems that this happens at different steps, when running COMPOSER_MEMORY_LIMIT=3G composer create-project -vvv --profile pimcore/skeleton my-project it happens at this step:

[642.5MB/21.00s] Reading /home/bernie/.cache/composer/repo/https---repo.packagist.org/provider-guzzle$plugin-md5.json from cache
[643.3MB/21.05s] Reading /home/bernie/.cache/composer/repo/https---repo.packagist.org/provider-guzzle$plugin-error-response.json from cache
[1434.7MB/27.24s] Reading /home/bernie/.cache/composer/repo/https---repo.packagist.org/provider-phpunit$dbunit.json from cache

and later here:

[692.8MB/84.79s] Reading /home/bernie/.cache/composer/repo/https---repo.packagist.org/provider-symfony$lock.json from cache
[885.4MB/86.64s] Reading /home/bernie/.cache/composer/repo/https---repo.packagist.org/provider-symfony$propel1-bridge.json from cache
[1702.3MB/97.86s] Reading /home/bernie/.cache/composer/repo/https---repo.packagist.org/provider-rhumsaa$uuid.json from cache
[1709.1MB/97.94s] Reading /home/bernie/.cache/composer/repo/https---repo.packagist.org/provider-doctrine$phpcr-odm.json from cache

[dpfaffenbauer]

Have you tried providing a composer.lock file in the skeleton? this could help a lot in reducing memory.

[brusch]

Yes, with a composer.lock in place the memory usage doesn't go over 30MB - so that would be a possible way to go. However I'd prefer a solution without the need of providing a composer.lock, as this would result in additional effort of keeping them up-to-date for the various install packages.

[brusch]

Removing all tags/branches < 5.4.0 doesn't make it any better, same issues are occurring.

[koschos]

Does anybody have other suggestions on this issue? we've got on 15G over in memory and now trying to fix this asap. Probably changing minimum-stability from dev to stable will save the day.

[dpfaffenbauer]

@koschos, what do you mean? There is no minimum-stability defined in the Pimcore composer.json.

[brusch]

Solved by providing a composer.lock for both the skeleton package as well as for the demo package. There's nothing else we can improve from our side, let's hope for the best that Composer is soon able to improve the SAT process :)