-
Notifications
You must be signed in to change notification settings - Fork 82
Improve substitution package handling and filter uses locally #1124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Test Results 540 files - 270 540 suites - 270 1h 49m 33s ⏱️ + 24m 43s For more details on these failures, see this check. Results for commit 8c4e76c. ± Comparison against base commit 25234a4. This pull request skips 1 test.♻️ This comment has been updated with latest results. |
9c46d7b to
5971533
Compare
|
I now finally sorted out the problems with the test. For my testcase it is Before: Resolve takes 66 sec and needed to process 2663 permutations |
|
I was now able to capture this into a database dump and use it as a testcase here: The testcase takes 71,5 seconds on my system and requires to process 2661 permutations without my change. Most notable, it reduces the uses permutations created from 31623 to 1(!) and the package permutations from 9272 to 172 meaning it can capture most of uses-constraint violation before they are actually surfacing! |
ac6eee2 to
78b2377
Compare
|
testLargeSet goes down from 2m 11sec > 13 sec now! |
Hubba bubba 😀 |
ec6b508 to
850d63c
Compare
31cc157 to
3d6f728
Compare
3d6f728 to
26d8e8f
Compare
|
This pull request changes some projects for the first time in this development cycle. An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch. Git patchFurther information are available in Common Build Issues - Missing version increments. |
87182b6 to
c0dd976
Compare
|
I now fixed some issues and now the testcase even goes down to 0,4 sec on my system and is able to complete with only one performed permutation. That mean that through local optimization we can compute a solution immediately. I'll try to add one more testcase and have to analyze once case where we produce a permutation that was previously not required (but that might be due to the changed algorithm) and then think it would be good to merge this to discover possible problems but from the usual test-cases I can't find any issues with this anymore and it incredibly reduces the computation times. |
a15d037 to
5fbdbc2
Compare
5fbdbc2 to
680aece
Compare
680aece to
e9eee54
Compare
e9eee54 to
f2341a8
Compare
Currently substitution packages handling can lead to a situation where the number of performed permutation increase considerably and the finding of a solution takes very long. In some cases it even times out and results in a failed resolve state. This now is improved by the following changes: When a permutation is removed from the stack, every requirement is checked if it is a substitution package and then resolve it to either external or internal case first: - if more candidates exits for this requirement a permutation is added to account for this alternative solution - now all other providers except the current one are dropped to make this a single provider as the choice can not be reverted and therefore other permutations in this path will be invalid - then it must be checked if the package resolves to an external provider in which case we need to drop the exported package capabilities of this bundle for the given package - after that all requirements are checked if they have only a single provider (what can happen independently or as part of the resolving to either external or internal) the use constraints are checked if they are in conflict with a currently selected provider and dropping such invalid choices - finally after that we check the package space consistency (that is a far more expensive check) what probably will result in more permutations created and checked until we found the best result to use
f2341a8 to
8c4e76c
Compare
Currently substitution packages handling can lead to a situation where
the number of performed permutation increase considerably and the
finding of a solution takes very long. In some cases it even times out
and results in a failed resolve state.
This now is improved by the following changes:
When a permutation is removed from the stack, every requirement is
checked if it is a substitution package and then resolve it to either
external or internal case first:
to account for this alternative solution
this a single provider as the choice can not be reverted and therefore
other permutations in this path will be invalid
provider in which case we need to drop the exported package capabilities
of this bundle for the given package
provider (what can happen independently or as part of the resolving to
either external or internal) the use constraints are checked if they are
in conflict with a currently selected provider and dropping such invalid
choices
far more expensive check) what probably will result in more permutations
created and checked until we found the best result to use
As this is a rather fundamental change there is a kill-switch
When setting
-Dfelix.resolver.substitution.legacy=trueon the JVM it switches back to the old behavior.