-
Notifications
You must be signed in to change notification settings - Fork 65
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
refactor: make solver generic #245
Conversation
Ah this is far from done. There are many more tests to fix. |
Good to go now! @wolfv |
I think you need to use |
Here are my measurements on macOS :)
|
@wolfv very interesting! In the simple case the port seems faster whereas in the larger case its much slower. |
Yeah, but we need to take the measurements with a grain of salt because of laptop / cpu warmup etc... but it's great to have some benchmarks! |
@wolfv I think this is ready to go! |
This refactors the code a little bit to make SolverTask and SolverBackend a bit more generic. The biggest change is that a SolverBackend can use any SolverTask where the available_packages are a container of which the elements are RepoDataRecords which can be borrowed.
The nice thing about this is that now its easier to create functions that are generic over the SolverBackend. This was required to make tests that are only used when certain backends are enabled without having to copy code per solver.
Additionally, I split the two solvers into separate modules so we don't get
LibSolvRsSolver
names but can uselibsolv_rs::Solver
instead.Also added some benchmarks. On my machine: