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. >
I don't entirely know why BuckleScript is so much faster than Elm and Fable, and admit that I am guessing about the objects version the arrays, but I do know that I have written purely functional benchmarks that are several times faster with BuckleScript than with Elm and even more times faster than Fable using identical algorithms and this is without the comparison issue that started the thread (manually bypassed in the inner loops, or primitive comparisons are not necessary). One of the main differences to be obviously seen in the produced JS code is arrays versus tagged objects so I jumped on that. Hongbo would better know what the reasons for slower code are. > > >> 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. > As long as all compiler changes happen only through Even, I agree that this is not going to happen in the short term. That's why I was looking to get involved if the issues could be solved with just a new Code Generator, but I am finding that some significant changes would likely have to be made earlier in the compilation pipeline. > You seem very earnest, though, so I suppose we'll have to agree to > disagree. > Oh, I can see your point that speed is not an issue for many users, especially if many users are coming from something even slower or noobies are coming from use of a dynamically-typed interpreter environments such as Perl, Ruby, standard Python, etc. It's just that I come from the old school where extracting the most from every computer resource mattered and i hate to see these resources wasted: to me, code that is three times faster means that one can get three times as much work done in a given time on a given machine, and this is true even for single-threaded web pages as one can have three times as many pages open at the same time with the same page lags. If you are interested, I can post a couple of the math oriented little benchmarks I have been using; as I know Elm isn't going to do very well against imperative type code with its current libraries, these are written purely functionally. One of the programs is an incremental functional prime number generator, which although a few times slower than the same algorithm in BuckleScript is quite a bit faster (20 times) than the one in the current user contributed elm-arithmetic library that is a naive translation to Elm from imperative code. Another is a purely functional version of a Hamming (Smooth 5) number sequence generator. Other benchmark programs have similar ratios to BuckleScript. If anyone is interested, I can post them. -- 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.
