100

I'm not sure what's causing this issue, but in a project, I'm building, the compiler is taking hours just to compile a module. The total size of my codebase is 352KB, but none of the modules are over 10KB large. I am using a Native port, but it's very trivial; I'm just fetching Date.now() with it.

Is there anything well-known that would cause the elm compiler to take forever to compile? I don't have many dependencies, but I'm using Html a lot. I would really appreciate any hints as to what would cause this.

Edit

So it turns out large case expressions will cause the optimizer to take a long time, as of 0.16. Here's the discussion on Elm-Discuss bringing up the issue, and a gist of the nasty case match.

I guess to be verbose and to keep a carrot out there, why would elm's compiler take this route for case-matching? What's the underlying machinery going on here? Why would the compiler take longer than an hour for optimizing 60+ pattern matches on a case statement?

radrow
  • 6,419
  • 4
  • 26
  • 53
Athan Clark
  • 3,886
  • 2
  • 21
  • 39
  • 4
    I'm curious. What kind of optimization is the Elm compiler performing that it takes hours to compile a case expression? Your case expression doesn't seem too big (at least not big enough for a computer). This means that the Elm compiler has a really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really bad optimization algorithm. For example, imagine how long it would take for it to compile a case expression with all the 721 pokémon. – Aadit M Shah May 04 '16 at 02:02
  • 5
    I guess the answer lies [here](https://github.com/elm-lang/elm-compiler/blob/master/src/Optimize/Case.hs), maybe you should try adding `haskell` tag and see if haskell people can reveal something to us. – halfzebra May 04 '16 at 08:25
  • @halfzebra, I have no idea what that code is doing, but I'm deeply suspicious of any code that uses `Data.Map` with `Int` keys. `Data.IntMap` is usually far faster for that. – dfeuer May 10 '16 at 21:32
  • 1
    In particular, I'd expect `unionWith`, which is used heavily in that code, to be much faster with a PATRICIA tree than a balanced binary search tree. – dfeuer May 10 '16 at 21:39
  • @dfeuer if you feel that you're on to something, then you're more than welcome to post the answer. – halfzebra May 11 '16 at 10:49
  • 5
    I think you should ask a new question in a better venue on fixing the case stuff, and answer your own by just explaining that case stuff is known slow. As to why, the relevant code looks to be here: https://github.com/elm-lang/elm-compiler/blob/master/src/Optimize/ The cited Scott & Ramsey paper describes how the "small branching factor" heuristic is disastrously slow. In the above code that heuristic is used as a tiebreaker when small defaults ties. So, I bet in your bad examples, small default ties a lot and we hit the horrible case. My take: Elm shouldn't use SBF as a factor, full stop. – sclv May 14 '16 at 06:02
  • 24
    Can you please self-answer this question so it doesn't appear on the unanswered list any more? – Julian Leviston May 28 '17 at 03:19
  • there are some ways of implement the same behaviour, just reimplement it in some other way while this is being fixed – Netwave Sep 11 '17 at 21:34
  • 6
    Did it ever actually finish compiling? – Worthy7 Nov 15 '17 at 01:27
  • I never did get it to finish, but I worked around it by using Ints instead. – Athan Clark Nov 16 '17 at 02:22

1 Answers1

4

Large case expressions will cause the optimizer to take a long time, as of 0.16. Here's the discussion on Elm-Discuss bringing up the issue, and a gist of the nasty case match.

Philip Whitehouse
  • 4,293
  • 3
  • 23
  • 36