Unbounded constraints impact memory usage / execution time

[bobdenotter]

Hi all,

I've noticed that using unbounded constraints like "symfony/foo": "*" together with "extra.symfony.require" makes for a project that's easy to update. Doing so severely impacts both execution time as well as memory usage.

In my tests, I've taken a slightly modified composer.json from symfony/demo, locked on 4.1. File here.

In all tests, I've cleared the setup as well as composer's cache:

rm -rf composer.lock vendor   
composer clearcache 

First, I tested it with all symfony/foo constraints set to ^4.1, and ran:

time COMPOSER_MEMORY_LIMIT=-1 memusg composer install

time is a utility to measure execution time, memusg is a small script that polls for memory usage, from here.

The results are:

• composer install 16,59s user 6,89s system 42% cpu 54,963 total
• memusg: peak= 1209472

Next, I've set all the constraints to an 'unbounded' *, and ran the same commands as above. Results:

• composer install 36,76s user 7,93s system 61% cpu 1:12,52 total
• memusg: peak= 2302040

Finally, I've reverted the constraints back to ^4.1, but I removed the extra.symfony.require and ran the same commands. Results:

• composer install 16,84s user 6,73s system 42% cpu 55,991 total
• memusg: peak= 1208248

So, comparable to the first case.

You'll see that using unbound constraints took twice as long (37 vs 17 seconds), and uses almost twice as much memory(2.3 GB vs 1.2 GB). I have no idea if this is something that we can fix, because dependency resolution is hard and complex, but I just wanted to point it out. In the current situation I'd advise people to keep their constraints locked down as much as possible, because of the above.

Pinging @weaverryan :-)

[nicolas-grekas]

Thanks for the report. Surprisingly, that's directly contradicting both experience and previous benchmarks.
Any idea why?

[bobdenotter]

@nicolas-grekas No idea, yet.. I'm seeing similar results with that composer.json from symfony/demo on my local dev machine(MacOs Mojave, php 7.2.11, Composer 1.7.3), as well as on two different linux machines.

I have repeated the tests on a stock symfony/website-skeleton install:

composer create-project symfony/website-skeleton symfony-skeleton
cd symfony-skeleton
rm -rf  composer.lock vendor
composer clearcache
time COMPOSER_MEMORY_LIMIT=-1 memusg composer install

results:

• composer install 24,96s user 7,60s system 46% cpu 1:10,64 total
• memusg: peak= 1665212

I then edited the composer.json, and set all symfony/foo constraints to ^4.1, and the symfony/bar-pack's to ^1.0. Ran the above commands again, with these results:

• composer install 15,08s user 6,99s system 38% cpu 57,779 total
• memusg: peak= 833864

So, comparable results as before, but no clue yet as to why.. Any idea what I might be doing wrong to get these different results than you did? I'll also happily test some more with another composer.json.

[stof]

well, for the initial run, Flex is not installed yet (as you don't have any vendors), and so Flex does not optimize anything based on extra.symfony.require. I think you are comparing ^4.1 to * with raw composer here (and so the stricter requirement is indeed better)

[stof]

@nicolas-grekas were you running these benchmarks with Flex installed globally ? Or maybe on updates rather than the initial install of the vendors ?

[nicolas-grekas]

were you running these benchmarks with Flex installed globally ?

that's quite possible yes

Or maybe on updates rather than the initial install of the vendors

note that since we commit composer.lock in skeletons, that bootstrap overhead doesn't exist when creating new projects from them

[nicolas-grekas]

All good then :)
I'm closing as all is explained.