Work around poor GHC performance on MinJoinR and ConstUnionR#71
Work around poor GHC performance on MinJoinR and ConstUnionR#71dwincort merged 2 commits intotarget:masterfrom
Conversation
GHC uses exponential(?) amounts of memory on MinJoinR and ConstUnionR when there are nested calls with many overlapping keys. This can be worked around by specializing `Ifte` to the branches we need in the two cases.
|
This seems great! I didn't realize that I should have some time either this weekend or next to play around with the checks and figure out why they're failing, and then I'll happily merge. As a side note, I wonder if there's a way to upstream |
|
@goldfirere linked me to this https://gitlab.haskell.org/ghc/ghc/-/issues/18965, which looks like it might solve the problem. |
dwincort
left a comment
There was a problem hiding this comment.
Thanks so much for upstreaming this change, and thanks also for showing me the neat trick of limiting GHC's memory in the test case to check for memory leaks! I hope GHC gets fixed in the future so that a type family like Ifte is once again usable, but in the mean time, I'll try to be careful.
Also, it's pretty cool to see people using row-types in the wild. I think your team is using variants in a bigger way than I ever have, which is surely how you found this memory bug. Let me know if you run into other issues in the future, as I'd be happy to help if I can.
GHC uses exponential(?) amounts of memory on MinJoinR and ConstUnionR when there are nested calls with many overlapping keys. This can be worked around by specializing
Ifteto the branches we need in the two cases.