> > 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. > 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. You seem very earnest, though, so I suppose we'll have to agree to disagree. -- 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.
