We do have around 12 passes to optimize js code, will have more advanced optimizations coming in 1.5 Note the optimization is written carefully so it will not slow down compile time. To squeeze the compiler performance, some performant critical code was changed to c in recent release On Thu, Jan 12, 2017 at 10:42 AM OvermindDL1 <[email protected]> wrote:
> On Wednesday, January 11, 2017 at 10:43:11 PM UTC-7, GordonBGood wrote: > > On your advice, I've reread the ReasonML documents as I got mislead by > looking at ReasonML/Rebel and that is at too early a stage for me to > consider (also support for BuckleScript is currently broken). I liked the > ReasonML syntax much better than OCaml as it is more consistent, although > it still has curly brackets and semicolons instead of white space delimited > block, I can live with that as long as I have before as long as it is > consistent. Unfortunately, I can't get the ReasonProject to install on my > machine (Windows 10 64-bit) and I am not likely to pursue it at this time > as it isn't *that* important to me. > > > I'm actually not a fan of the Reason syntax myself, I consider it horribly > verbose and noisy, but then again I've been comfortable with OCaml/SML > syntax for over a decade now. However correct, Reason has no Windows > support 'yet' (it is on their roadmap), however bucklescript works > perfectly with its HEAD right now elsewhere (most of the windows issues > are, oddly enough, because of npm stupidity actually). Bucklescript itself > supports windows absolutely perfectly though (I was noisy about it at first > when it was not ^.^). > > However, I can see how you'd like the Reason syntax better, but do not > discount the OCaml syntax. The nice thing about the OCaml raw syntax is it > is not only blazing fast for the compiler to parse, but also for a human to > parse as well, you know what things will be once you learn it, and it is > very simple. > > > On Wednesday, January 11, 2017 at 10:43:11 PM UTC-7, GordonBGood wrote: > > I understand that if I were able to install it, by "working seamlessly > with BuckleScript", you mean that the "bsb" command will just take the > output of the previous ReasonML build as its input to produce JavaScript? > > > Actually Reason's build system can choose bucklescript as its output > directly, it has first-class support. However you could indeed translate > reason -> ocaml -> bucklescript pretty easy anyway. > > > On Wednesday, January 11, 2017 at 10:43:11 PM UTC-7, GordonBGood wrote: > > BTW, I see one of the reasons that BuckleScript produces JavaScript that > is so much faster than that produced by Elm: you use JavaScript Array's as > the base for almost all of the data structures whereas Elm uses tagged > objects, which are very slow (at least on Google Chrome V9/nodejs); it > almost seems like the Elm compiler just outputs dynamically typed code with > the "all data is just one type - an object with tags" model, although it > does recognize that numbers, characters, and strings will be picked up by > JavaScript and don't need to be wrapped in a tagged wrapper object. > > > That is one person, but not the only one. A bigger reason is that > bucklescript 'types' the javascript code, such as by putting `| 0` on > integer operations and such, which allow most javascript VM's (V8 and > especially Firefox's) to pre-JIT them significantly more efficiently. > However it has more 'typing' that it can do, which I expect over time. > However yes the array's are more efficient, and it matches what OCaml > itself does (array's of bytes to store data). > > > On Wednesday, January 11, 2017 at 10:43:11 PM UTC-7, GordonBGood wrote: > > Its too bad you can't apply your compiler optimizations to Elm. Perhaps > they could be, as Elm does produce an AST and is a very simple language so > presumably the AST is fairly simple too. > > > Bucklescript does not do the optimizations itself (well it does some > javascript-specific one like higher arity functions and so forth), most of > it is OCaml. *However*, you could write an Elm compiler that compiles to > OCaml (which then could be compiled to native or to > javascript-via-bucklescript), but the syntax's are so close as it is that > it would be easier to just write an elm-like library for OCaml instead. > > > On Wednesday, January 11, 2017 at 10:43:11 PM UTC-7, GordonBGood wrote: > > As an aside, have you ever looked at using an asm.js back end as current > mainline browsers mostly support it, and if so did it make any different to > speed? > > > Actually that is what the typing stuff I mentioned above is, it is the > asm.js decorations (though not full asm.js, things like '|0' is pretty > universally supported, plus it is all backwards compatible). I could > imagine OCaml compiling directly to webassembly later anyway, but for > working with javascript being able to see the (very readable) output > javascript via bucklescript is unmatched in usefulness. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Elm Discuss" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/elm-discuss/Um7WIBTq9xU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
