Unbearable compile time

[Daniel Popeski]

This question is almost completely directed towards Evan, but to anyone who could help, i'd be in debt. 

As our project grows significantly, things are getting out of hand when we try to compile it. Up until today, we were aware of a certain module (the routes) that if modified, we would need to wait for about an hour for the build to finish.

However with the latest set of changes we've done, it's been almost two hours, and it's still not done building.

I've raised this issue with Noah and Luke in their webcast, and Noah seemed to at least be aware of the issue.

The compile time seems to be heavily affected by case-statements with a lot of branches which we do have A-LOT-OF. 

Our app has quite a few routes and sub-routes and they are represented with ADTs.

Now, since the github issue is closed, why isn't there a minor Elm update that fixes this productivity killer?

Does anyone have any idea of what could I do in meantime?

[Yosuke Torii]

I ran into the same problem and found a workaround. It was simple. Just dividing into two nested case-of trees.

In my case, the app has a lot of shortcut key patterns.

handleShortcut ctrl shift key =

  case (ctrl, shift, key) of

    (True, False, C) -> ...

    (True, False, V) -> ...

    ... a lot more branches here ...

I changed this into something like below.

handleShortcut ctrl shift key =

  case (ctrl, shift) of

    (True, False) -> ...

      handleShortcutWithCtrl key

    (False, True) -> ...

      handleShortcutWithShift key

    ...

handleShortcutWithCtrl key =

  case key of

    C -> ...

    V -> ...

This saved my time a lot. (still waiting the next version, btw)

Is this way possible for your case too?

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/b50e606d-aad6-4964-928e-8f197ade6148%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eirik Sletteberg]

Is it possible to turn off the exhaustiveness checker? I guess  that's a part which can take a while.

If it's not possible to turn it on with a compiler flag, you could try forking the compiler code and making a version where you have commented out the exhaustiveness check.

(Though I'm not 100  % sure that's the slow part of the compiler)

[Zachary Kessin]

Is this on a VM? There is an issue with builds taking a very long time on a VM due to haskell thinking there are more cores than it should. There is a fix for that by using sysconfcpus

Of course it could have nothing to do with that

Zach

ᐧ

--

You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/a2cb0c46-433f-4909-940f-cd49cb3dd7fa%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Zach Kessin

Skype: zachkessin

+972 54 234 3956 / +44 203 734 9790 / +1 617 778 7213

[Richard Feldman]

Daniel - Evan posted some binaries that specifically speed up exhaustiveness checking as well as parsing. I don't know if your code base will be compatible with this (there were some breaking changes which might not be compatible with all the libraries you're using), but it might be worth a try.

Releases are really time-consuming, not just for Evan but for the community; everyone has to update libraries and push updated releases. Please keep that in mind, and that Evan is working hard on shipping 0.19 - which would of course include these speed improvements, among the other things he's been working on.

[Daniel Popeski]

@Yosuke: Not possible with ADT of ~40 values.

@Erik: That's out of my reach

@Zachary: No, just a many-cored hella-powered personal machines.

@Richard: I was inferring on publishing the fixes/optimizations in a version of something like 0.18.1 - no api change of whatsoever. Thank you for pointing me to the binaries tho. It would've been awesome temporary solution if it didn't have the boolean pattern matching bug as well as one where what is compiled, cannot be recompiled unless elm-stuff is deleted.

Btw, if anyone wondering, the compilation is NOT going on till this day. It ended couple of minutes after i wrote that. So 1hr 50min in total. 

I really hope Evan would publish some intermediate binary, otherwise, I would need to wait for 0.19 to add another route to the app.

[Rupert Smith]

On Saturday, March 25, 2017 at 6:32:45 PM UTC, Daniel Popeski wrote:

Now, since the github issue is closed, why isn't there a minor Elm update that fixes this productivity killer?

Does anyone have any idea of what could I do in meantime?

Would applying the patch for the github issue to 0.18 and then building your own 0.18.1 compiler locally work? Or the patch does not cleanly merge in/work correctly when doing this?

[Eirik Sletteberg]

To be fair, compiling elm yourself is quite tricky today. The initial compile takes hours (but I guess you're already used to that) and you need to clone the elm-platform repo and follow instructions. (Except apply the patch before running the build)
I hope 0.19, with a single binary, will make the process easier!

[Evan Czaplicki]

Daniel, the folks in this thread have given you all the information for a temporary fix.

It doesn't matter if you have 40 or 100 constructors. The performance bug manifests when you use tuple patterns like this. There is no situation when you must use a tuple in a case. You can always break that into nested cases. Yosuke demonstrated going from 3-tuples to 2-tuples.

As for the Bool bug, again, you can break it into a nested if expression.

There are many folks here who can demonstrate how to do both of these things. Please ask on #elm-dev on slack if you need help with either idea.

It would be great if the fix could just be released, but it is tied in with the new parser, which has breaking changes. That means a 0.18.1 is not possible without doing very serious surgery on the existing code to extract the new parser. I would want at least a week of community testing before releasing something like that. So as Richard already said, this is very time consuming to do well. A compiler is not like an npm library. For your case, I should "just do it" but for the rest of the community, I cannot justify spending a week on a risky release for a bug with many known workarounds.

So the fix will be out with 0.19. If you make some temporary changes described by multiple posters here, you should be able to bring the compile times down significantly with 0.18, not even needing the preview.

On Mon, Mar 27, 2017 at 4:18 AM, Eirik Sletteberg <eiriksl...@gmail.com> wrote:

To be fair, compiling elm yourself is quite tricky today. The initial compile takes hours (but I guess you're already used to that) and you need to clone the elm-platform repo and follow instructions. (Except apply the patch before running the build)
I hope 0.19, with a single binary, will make the process easier!

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/f4bb6ffb-a16f-4886-af96-b3757199dfa1%40googlegroups.com.