fork every time we see a non-trivial marker ("aggressive" forking) #6143
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit switches our forking strategy to one that always forks when a marker expression is encountered, even if there is only one dependency specification. This results in a perf regression but it is believed, at present, to be necessary for correctness and for stability in the lock file output.
CodSpeed Performance ReportMerging #6143 will degrade performances by 83.07%Comparing Summary
Benchmarks breakdown
|
Member
|
I'm going to close this as it's quite stale now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a revival of #5733 on top of current
main, as many thingshave changed since #5733.
It is suspected that, at least at this time, we probably don't
want to switch to aggressive forking, but we may in the future. In
particular, aggressive forking does fix #4668 and #6127.
Moreover, it fixes some issues that aren't filed but for which we only
have hand-crafted artificial examples (see the
non-local-*packsescenarios).
There are two main downsides to aggressive forking:
overall, sometimes dramatically so.
understand. Part of the point of this PR is to be able to look at the
snapshot diffs to see the kinds of effects it has. In some cases, the
changes are quite large and can be difficult to comprehend and reason
about.
We haven't spent a ton of time on (1), but it is suspected that in the
aggressive strategy, there should still be a way to prune superfluous
forks.