Bad worst-case performance for pattern match compiler

[evancz]

When you have large, complex pattern matches, it can trigger bad performance during the optimization phase. This issue is for organizing http://sscce.org/ that illustrate this problem:

• https://gist.github.com/athanclark/0e29485cb245ff07a97730cfef365d10
• The main logic in Dict

The solution is known. If you suggest another example for some reason, please link it as a gist. We may delete your comment to keep this issue simple and clear.

---

Update: This is dramatically improved in the draft for 0.19. Read about that here.

[treeowl]

Where is the known solution? A non-invasive change that I suspect would likely improve matters substantially (although perhaps not enough) would be to switch from Map Int to IntMap.

[gbaz]

So I skimmed the "When Do Match-Compilation Heuristics Matter" paper cited in the Optimizer source. It describes that the Small Branching Factor heuristic is unusably slow. Here it is used apparently as a tiebreaker when Small Defaults doesn't suffice. So -- if you have something where Small Defaults generates lots of ties, you will be tossed into the pessimal case and things will grind to a halt.

It seems to me that the Elm compiler should simply avoid heuristics, even as fallbacks, which have such terrible worst-case performance, as it makes the compiler unpredictable.

[Ryan1729]

If you change a flat pattern match to a series of nested pattern matches, the (0.17.1) compiler has a much easier time of it. Would having the compiler perform a pass to convert pattern matches of tuples into this form be a good way to address this problem?

Here's a faster to compile version of the month example linked above.

And here's a slow and a fast version of a different example.

[pyladune]

Is there a simple to identify during compilaiton which part of the code creates such situation ? or at least file ?

[JoeyEremondi]

Doing the conversion from flat to nested is, by my understanding, exactly why the compiler is taking so long right now. Making them nested in your code makes you do the work instead of the compiler, which speeds up compilation. Have you tried 0.18? I think the pattern match compiler got an overhaul to fix the performance issues.

…

On Jan 29, 2017 11:08 AM, "Seb" ***@***.***> wrote: Is there a simple to identify during compilaiton which part of the code creates such situation ? or at least file ? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1362 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACzn0hQbfLjBBZ4hi5ETsbeL9ihdmFFvks5rXOOngaJpZM4IWoxf> .

[cscalfani]

Here's an example of the bug in 0.18. Hopefully, this helps: https://gist.github.com/cscalfani/8c84015c4ce34a31c06776b67cd57ef1

[evancz]

I fixed this. You can read about it some here. The faster version will be out with 0.19, so I'll close for now.

If any folks reading this issue see new ones pop up reporting the same thing, please refer them here or the elm-dev posts that follow up on that status report.