-
Notifications
You must be signed in to change notification settings - Fork 412
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
pkg: don't expand deps of restricting deps #11264
base: main
Are you sure you want to change the base?
pkg: don't expand deps of restricting deps #11264
Conversation
@talex5 do you mind doing a sanity check on this? |
Is it possible to add a test to demonstrate a change in behavior? Since this change is loading opam files, I imagine that it should avoid raising an error when one of these opam files has an error. |
This change sounds reasonable to me. |
Upstreaming would be good. It would likely make the solver service a fair bit faster. |
Previously dune would expand dependencies of packages that are only ever marked as conflicting with packages in the solution. This led to the expansion of far more packages that necessary. Expanding a package requires reading an opam file and so is a relatively expensive operation. For packages that only depend on the compiler (ocaml-base-compiler), this reduces the number of expanded packages from 8376 to 1841 at the time of writing. Signed-off-by: Stephen Sherratt <[email protected]>
Signed-off-by: Rudi Grinberg <[email protected]>
Signed-off-by: Rudi Grinberg <[email protected]>
Signed-off-by: Rudi Grinberg <[email protected]>
1a64582
to
8a12dfc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Rebased the conflicts and added some minor cleanups
Previously dune would expand dependencies of packages that are only ever marked as conflicting with packages in the solution. This led to the expansion of far more packages that necessary. Expanding a package requires reading an opam file and so is a relatively expensive operation.
For packages that only depend on the compiler (ocaml-base-compiler), this reduces the number of expanded packages from 8376 to 1841 at the time of writing.
Consider this to be a proof of concept demonstrating the problem and a potential solution. "Better" solutions might avoid the additional mutable state I've added here but would probably be more invasive. Since we've discussed eventually rewriting the solver anyway, I'm happy for this to be merged if my approach is deemed acceptable.
Here are the performance stats (using this feature) before and after this change on my machine (also including #11254 as it removes a large constant factor (technically
O(num-pkgs-in-repo)
) from the solver runtime). The project being locked has a single dependency onocaml-base-compiler
.