Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[Ready for Review] Slightly improve performance #2299
@cloudRoutine Thanks for taking a look, but that is a really early version. =)
Stylistically, I need to clean it up and revert a bunch.
The relevant change to review is
very confident, working on this one is annoying isn't it?
it looks like it's cutting out too quickly now
I think another quick win may be ordering the Requirements so that fixed versions are resolved first.
E.g. I was testing #2294 (comment) and noticed the following warning:
But logically speaking, that warning is backwards.
At the moment it seems to resolve it in the order it is specified in paket.dependencies:
I'm not really happy with how the current check works - it just compares the name of the conflicting requirements to the names of the previously solved requirements and if it can't find one it just re-solves the previous one (which is what it did before). So there may (and surely are) still degenerate dependency files which will take forever to solve.
The correct way would be to walk the whole dependency chain and check if any conditions actually conflicts.
My plan (for this evening) was to split this in two PRs:
Now I don't think the resolver change is bad - the unit tests pass, so it shouldn't actually make it worse - but it is far from perfect, so it may be worth it to pull now anyway and improve it later.
If you want to merge it NOW, feel free to cherry-pick and clean up the changes to PackageResolver.fs
( I can't push from behind the work-firewall ...)
I did a quick benchmark, and it looks like foldback has a relatively high overhead: https://gist.github.com/0x53A/d6d30523e04c7e1c448668546c6d69f9
The Resolving is only cpu bound if the algorithm degrades. That means the really relevant part was the change to
Currently it still degrades in a few situations, but it is already better than before.
Especially the last two commits are completely unnecessary performance-wise, my main motivation was readability and extracting it to a helper function, the benchmark was just curiosity.
For performance testing, it would be great if you had any other dependencies files which did correctly solve before (so that we can actually compare numbers), and took maybe a minute or two, so that we don't need to wait too long.
For the next round of improvements I want to set up a benchmark script that checks out a git sha, builds it, and runs a few paket installs against a few different paket.dependencies.
Before: didn't finish after an hour
The original paket.dependencies from the issue fails with an error, but this reduced one resolves correctly. (see #2305 for the failure)
With an older version (I assume pre 5.alpha) cloudroutine could resolve the second file in 2 minutes, now it takes me 5 minutes on this branch, so this may be worth investigating.
ref #2294 (comment)
But it seems unrelated to this PR, because with 5.0alpha I'm still waiting for it to finish, and 5 minutes is better than never =).
Having seperate printfs would certainly help a bit to show where the bottleneck lies, but I don't think most users actually care, they just want it to work, otherwise they would still just use neverget.