I would suggest we stop further discussions since it is quite lengthy and doesn't make too much sense.
No matter how much better job BuckleScript did, the 'Evan knows' means it will be solved magically soon, this is a little unfair to my work. I understand there are lots of factors when choosing a language, as long as you enjoy it, then it's great. Have fun with your favorite language! On Tue, Jan 24, 2017 at 11:53 PM Bob Zhang <bobzhang1...@gmail.com> wrote: I have been working on compilers professionally for more than 8 years, I did not read your ocaml code, so I am not sure it's performant ocaml code. But anyway, I think you already convinced yourself elm suits your need better :-) On Tue, Jan 24, 2017 at 11:44 PM GordonBGood <gordonbg...@gmail.com> wrote: On Tuesday, 24 January 2017 09:37:32 UTC+7, Richard Feldman wrote: The reason is that BuckleScript proves that Arrays are faster than "string" tagged objects and I have tried benchmarking it myself. In fact, I have gone further and manually substituted the use of Arrays rather than the string tagged objects in the generated Elm code to show that is the reason. The problem isn't so much the use of Array's versus objects/records, but the string tags, which as the Elm JS output doesn't preserve type information except by these tags, are continuously requiring string processing to determine the type of object at run time. Elimination of these strings by using the type information the compiler already has would greatly speed things even if objects are used, with the further advantage of Arrays being that their indices are numeric for slightly less processing (depending on the browser engine used). Modern JS engines intern string literals <http://stackoverflow.com/questions/5276915/do-common-javascript-implementations-use-string-interning>, making them in general faster than index-based Array access. I would definitely expect this idea to result in a performance regression for Elm, and I would be very surprised to see benchmarks to the contrary. With Robin Heggelund Hansen's help, I have determined that my problem is primarily the issue he already raised with Evan: that the static type information is not used in code generation so that equality and comparison conditions require an extra level of function calls, which problem is exacerbated by the tightness of the loops I am trying to write. In fact, other than for this problem, JS code produced by Elm is quite fast, at least on the Chrome V8 JS engine. My point is that for those of us that need speed - at least a few that have chimed in on this thread - if it isn't addressed with the Elm compiler then Elm might migrate to a front end to OCaml which would schism development efforts and possibly hurt the language. My other point is that the sooner it is done the easier it will be. And it doesn't affect those that find current Elm speed adequate - all that is needed is enough contributors and co-ordination between the different developments. I don't think any of this has even the remotest chance of happening. Why do you think that? I see that someone named Joey Eremondi did extensive work to improve optimization leading up to version 0.16 which made differences from several times to hundreds of times in improved execution speed. it turns out that I am suggesting much less than that: just the ability to make calls to the "isPrim" function for types and if true to just emit the direct JS operators rather than making a run time call to the general eq/cmp functions to let it be sorted out at run time. Further optimizations a la BuckleScript are more minor in effect and major in execution, effectively erasing some type information for minimal cases, but doing this would be much more complex as more complete type information would need to be available to the Code Generator. For instance, BuckleScript already knows the number of elements in a Tuple0 as compared to a Tuple2 so there is no need for a tag. and the same goes for records of various field names and numbers of fields. Joey's work already made Elm's handling of closures quite effective and in some cases better than BuckleScript as to elimination of the closure when it is inside a tail call optimized loop for many cases. Although off the subject of speed, it is something like the fairly minor change to make all current Elm types comparable (if comparing like types with like) so that Records and Union types/ADT's are also comparable as they are in OCaml/BuckleScript: the compiler already makes sure that both sides of a comparison are of the same type and kind; this would allow all current Elm types to be used as keys in Dict's/Set's and perhaps reduce the pressure on Evan to add type classes to the language. -- 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 elm-discuss+unsubscr...@googlegroups.com. 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
