-
Notifications
You must be signed in to change notification settings - Fork 691
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
Solver needs around 20000 backjumps to solve for servant-mock-0.8.3 #4976
Comments
Does this issue require
I think that the conflict between ansi-wl-pprint and the new version of ansi-terminal is the problem. The solver chooses ansi-terminal first and then chooses ansi-wl-pprint after following a chain of dependencies (servant-server, wai-app-static, optparse-applicative, ansi-wl-pprint). Here is a common pattern from the log:
The solver tries many combinations of versions for the four packages but can't resolve the conflict until it backtracks to ansi-terminal. I started working on #4805 to help with conflicts involving packages that are deep in the dependency graph, so I rebased it onto master and tried it with servant-mock. It finished in about 2.6 seconds, so I think that was the only problem. I'd like to fix the remaining issues with the branch and make a PR, though I'm not sure when I'll have time. |
@grayjay great! yes, IIRC |
I tested this change by comparing performance with both c01d92f (before any refactoring needed to implement this change) and 4d28102 (the previous commit), using hackage-benchmark. Since the refactoring changed the meaning of the backjump count, I only timed "install" commands that didn't reach the backjump limit. I chose several commands that ran for different amounts of time, including the long running example from issue haskell#4976. Comparing c01d92f (cabal1) and this commit (cabal2): compiler: GHC 8.2.1 index state: 2018-02-16T02:47:32Z extra hackage-benchmark flags: --packages="aeson yesod wolf" --pvalue=0.01 --trials=50 --print-skipped-packages package result1 result2 mean1 mean2 stddev1 stddev2 speedup aeson (not significant) yesod Solution Solution 2.270s 2.258s 0.027s 0.031s 1.005 wolf Solution Solution 7.337s 7.234s 0.056s 0.047s 1.014 Comparing 4d28102 (cabal1) and this commit (cabal2) with the same environment and flags as above: package result1 result2 mean1 mean2 stddev1 stddev2 speedup aeson (not significant) yesod (not significant) wolf Solution Solution 7.297s 7.245s 0.045s 0.048s 1.007 hackage-benchmark currently doesn't print the results when they aren't significant, so I reran "cabal install --dry-run aeson", and it ran for about 1.6 seconds and found a solution. Comparing c01d92f (cabal1) and this commit (cabal2) on issue haskell#4976: compiler: GHC 7.10.3 extra hackage-benchmark flags: --cabal1-flags="--index-state='2017-12-25T17:31:19Z' --enable-tests --max-backjumps=-1" --cabal2-flags="--index-state='2017-12-25T17:31:19Z' --enable-tests --max-backjumps=-1" --packages=servant-mock --pvalue=0.01 --trials=50 --print-skipped-packages --print-trials trial/summary package result1 result2 mean1 mean2 stddev1 stddev2 speedup ... summary servant-mock Solution Solution 39.693s 38.863s 0.181s 0.174s 1.021 Comparing 4d28102 (cabal1) and this commit (cabal2) on issue haskell#4976 with the same environment and flags as above: trial/summary package result1 result2 mean1 mean2 stddev1 stddev2 speedup ... summary servant-mock Solution Solution 39.659s 38.960s 0.195s 0.162s 1.018 Overall, this seems like a very small performance improvement.
This issue should be fixed by #5918. |
With GHC-7.8.4 or GHC-7.10.3 and
This is probably due recently released
ansi-terminal-0.8
, which is quite early in the dependency-graph:dependency-graph.pdf with
ansi-terminal
revdeps highlightedcc @grayjay you might like to solve this puzzle!
The text was updated successfully, but these errors were encountered: