On Saturday, January 14, 2017 at 3:13:40 PM UTC-7, GordonBGood wrote: > > I saw that over on elm-dev, but haven't tried it because compilation speed > isn't a problem for the Elm code I have written so far. The only reason I > brought it up is OvermindDL1's comment > <https://groups.google.com/d/msg/elm-discuss/Um7WIBTq9xU/JpNNGv1JAgAJ> that > compiling a Ocaml/BucketScript code (that presumably did the same thing as > the Elm code) took about 0.1 seconds as compared to 40 seconds with the Elm > compiler - a 400 times speed-up! We weren't given details of the code or > test conditions and whether one was an incremental compilation, but that > sounds quite serious and would affect the usability of Elm. If that data > is verifiable, a speed up of double or even quadruple doesn't begin to > touch the difference and should be investigated. >
It was a rewrite of a messaging system at work, it was in elm but we had issues that necessitated the use of too many ports, the new one written in OCaml (transpiled to javascript by Bucklescript) does the same thing in about the same lines of code, except no javascript was used at all. The lines of code is hovering around 6k for both versions, a compile for both is done just by calling elm-make or bsb respectively and those are the output times for a clean compile (no cache for either) with both spread across about 31 source files. I'm not sure why the elm compilation is so slow, the compilation is happening on Windows so that could be a factor. And sadly no, cannot release work code without consent. ;-) A note though, the elm code was severely hampered by the type system in Elm (lack of HKT's or HPT's) so had to get creative with use of records and unions, so it is entirely possible we hit a very slow case, in the OCaml code we used some GADT's and polymorphic modules so as to not resort to those hacks. On Saturday, January 14, 2017 at 9:14:55 PM UTC-7, Richard Feldman wrote: > > If only there were a binary posted somewhere, based on a compiler that had > just been rewritten to improve build times, so that someone could post a > benchmark instead of speculation! ;) I might be able to test out the new compiler, still have the old elm code in the repo (just that chunk is unused, we are still using other parts of Elm that are not as large and not as full-of-ports) if really curious? On Sunday, January 15, 2017 at 8:21:28 PM UTC-7, Richard Feldman wrote: > > you need recompile that module and regenerate a monolithic js file, the >> larger project it gets , the worse compilation time you get in elm mode. If >> you have experience in C++, you know the bottle neck used to be linking, it >> is quite common for a c++ project to spend 20minutes in linking. > > > Considering Evan is working on asset management for the next release, I > doubt "compile everything to one file" will be true after it lands. (That > release is presumably still several months away; this is just speculation > on my part.) > Ooo, now that would be awesome. :-) On Tuesday, January 17, 2017 at 4:25:08 AM UTC-7, Rupert Smith wrote: > > Yes, that is what I thought. I probably missed some context out when > quoting, but my question was in response to OvermindDL1's suggestion that > moving to OCaml would open up the possibility of compiling to different > back-ends other than javascript. > > An alternative might be to re-write the Native modules in the Elm core in > OCaml. There isn't a huge amount of it. > Precisely this, I've already done quite a large chunk of it as a test and it translates very easily (and becomes type safe, which Elm's is not as I've hit 'undefined's in pure elm code before (already in the bug tracker, but why did they happen at all?!)). I kept it identical to the Elm API as well, though if I broke Elm's API in a couple of minor ways then I could *substantially* reduce the number of allocations done... But yes, I've rewrote most of Elm's native Core code as well as some third-party libraries like navigation, all without a touch of javascript and all of it type safe the whole way, mostly playing around but we ended up using a lot of it at work anyway (I still need to get around to cleaning it up and releasing it...). An Elm->OCaml transpiler is entirely possible and I've no doubt it would take substantially less than a year to do (if I could get my work to pay for it I'd guess probably two weeks at most, though if everything goes well I'd guess two days for the language conversion and the rest on filling out the rest of the API that I've not yet done so as to remove all javascript, which would make it compileable to native code as well once system checks were added in, another chunk of time for that but not much). -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
