Sorry, typo... I mean data representation is not the only reason that BuckleScript runs fast On Mon, Jan 23, 2017 at 9:41 PM Bob Zhang <[email protected]> wrote:
> I agree, we did a lot of work to engineer performance, data representation > is part of the reason that BuckleScript running fast, it's definitely the > only one > > On Mon, Jan 23, 2017 at 9:37 PM Richard Feldman < > [email protected]> 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. > > > 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 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.
