Use CompilingMatcher in DefaultPolicy for performance reasons

[Toflar]

This needs more investigation for sure but I wanted to leave it here so others can investigate too.

I noticed that in the DefaultPolicy we do not use the CompilingMatcher which causes all constraints to be dynamically evaluated over and over again. Since the introduction of the PoolOptimizer, the DefaultPolicy is heavily used to select the correct packages within the dependency groups.

I did a few tests and this reduces the PoolOptimizer runtime by about 10%. The more packages in the pool, the higher the potential savings. In absolute times we're talking 0.2 - 0.5 seconds, maybe.

However, in order to make the tests pass, I had to add some dev- comparison which I'm a bit confused with. Things to clarify:

• Why is there Constraint::matchSpecific() and why is this a public method and not an implementation detail?
• Why does the CompilingMatcher handle this case differently - is this a bug in composer/semver?

[Seldaek]

The problem is we do treat branches differently here for ordering purposes than for normal constraint matches, hence you have matchSpecific with the second compareBranches: true param.

So IMO the only correct way is to keep doing this for branches and skip it otherwise.

I don't know if this negates the perf gains but I would imagine it still helps a bit? Can you check?

[Toflar]

It sure does. Here's how you can easily compare: composer update --dry-run -vvv --profile 2>&1 | grep optimize

main@755de04bf

[101.8MiB/3.93s] Running pool optimizer.
[142.4MiB/7.70s] Pool optimizer completed in 3.767 seconds
[142.4MiB/7.70s] Found 20,252 package versions referenced in your dependency graph. 17,241 (85%) were optimized away.

This PR@6d3db22

[101.7MiB/3.99s] Running pool optimizer.
[144.4MiB/7.44s] Pool optimizer completed in 3.457 seconds
[144.4MiB/7.44s] Found 20,252 package versions referenced in your dependency graph. 17,241 (85%) were optimized away.

I think that's an easy win for everybody 😊

[fredden]

Do we also need to worry about versions which end with -dev?

https://getcomposer.org/doc/articles/versions.md#branches

In the case of a branch with a version-like name (v1, in this case), you append -dev as a suffix, rather than using dev- as a prefix.

[Seldaek]

No because those get normalized like e.g v1 branch becomes 1.9999999.9999999.9999999-dev and that plays well with version compare. The problem is really named branches which aren't versions at all.

[Seldaek]

Alright then let's get this in, thanks!

[naderman]

@Toflar thanks! 🥳