Skip to content
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

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

gridbugs
Copy link
Collaborator

@gridbugs gridbugs commented Jan 2, 2025

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 on ocaml-base-compiler.

# before
$ dune pkg lock --print-perf-stats
Solution for dune.lock:
- ocaml-base-compiler.5.2.1

Expanded packages: 8376
Updated repos in: 0.91s
Solved dependencies in: 2.73s

# after
$ dune pkg lock --print-perf-stats
Solution for dune.lock:
- ocaml-base-compiler.5.2.1

Expanded packages: 1841
Updated repos in: 0.90s
Solved dependencies in: 0.45s

@rgrinberg
Copy link
Member

@talex5 do you mind doing a sanity check on this?

@rgrinberg
Copy link
Member

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.

@talex5
Copy link

talex5 commented Jan 7, 2025

@talex5 do you mind doing a sanity check on this?

This change sounds reasonable to me.

@gridbugs
Copy link
Collaborator Author

gridbugs commented Jan 9, 2025

@talex5 do you mind doing a sanity check on this?

This change sounds reasonable to me.

@talex5 would it make sense to upstream this change into zero-install or is there a case in general where it still makes sense to expand deps of restricting deps?

@talex5
Copy link

talex5 commented Jan 9, 2025

Upstreaming would be good. It would likely make the solver service a fair bit faster.

gridbugs and others added 4 commits January 9, 2025 22:49
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]>
@rgrinberg rgrinberg force-pushed the do-not-expand-conflict-only-packages branch from 1a64582 to 8a12dfc Compare January 10, 2025 00:04
Copy link
Member

@rgrinberg rgrinberg left a 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants