Tight calculation loops and performance matters a lot in some cases such as complex form validation. I've spoken with at least one company suffering these bottlenecks with Elm, but it was resolvable by just changing how the data is modelled.
For performance in production, if you're not running a game, then the longest computational time is likely from multiple re-renders. Which is thankfully not an issue. TBH, we do not care in production if Elm is the "fastest". We care if it is "fast enough", which it is. On Tue, Dec 27, 2016 at 2:01 PM, Robin Heggelund Hansen <[email protected]> wrote: > I was the one who raised the original issue. The reason there is only a 20% > performance in the given example is because the comparison operator isn't > the bottleneck of the code, which tests retrieving an object from an > immutable array with 10.000 elements. What you are testing is essentially > only measuring the overhead of a comparison operation. Still, my benchmark > is able to run at 7,5 million ops per second, running on a macbook air from > 2013. This is fast enough for most web apps, and this brings me to my next > point. > > Elm is, at least currently, a language to make web applications. How often > are you going to run calculations in tight loops where the performance > impact of comparison or equality operators gives a noticeable performance > impact for the end user in a web browser? > > I'm not saying that the proposed optimisation isn't worthwhile, it is. But > Elm, being a 0.x language still, has a lot more important things to improve > on before it turns its attention back to performance, which is already very > good. Things like hot-code reloading, improved package manager and bug > fixes. > > > tirsdag 27. desember 2016 03.41.29 UTC+1 skrev GordonBGood følgende: >> >> >> >> On Tuesday, 27 December 2016 05:37:43 UTC+7, Robin Heggelund Hansen wrote: >>> >>> Part I: Evan is already aware of this issue, you can see the full >>> discussion in this github issue: >>> https://github.com/elm-lang/elm-compiler/issues/1528 >>> The short of it is that the code generator part of the compiler is not >>> aware of type information, and adding this would be a serious undertaking. >>> It will probably come at some point, as there are interesting optimizations >>> that can be made, like the one mentioned >> >> >> Although it is good to see that Even is aware of the issue, it is >> discouraging to learn that the type information is not retained by the code >> generator and therefore this improvement is part of a "huge project"; thus >> the linked issue has been closed. The person who raised the original issue >> developed some timing results that showed only about a 20% speed improvement >> for the particular code use. However, when I compare the above tight loop >> written directly in JavaScript, the difference here is about 700%! Of >> course, real use cases won't be quite this large, but I could see a fairly >> tight loop being 300% (+/- 100%) faster. >> >>> >>> >>> Part II: Bitwise operators are inlined in 0.18, which gave a noticable >>> performance boost in libraries like Skinney/elm-array-exploration and >>> mgold/random-pcg. Having it available as a function (just like +, -, * etc.) >>> allows more flexibility like currying. >> >> >> I checked and you are right that these functions are now inlined. >> >> The only other thing they should also have is infix for those with two >> operands for better (conventional) clarity of code, but this is no biggy. >> >> It turns out that the huge slowdown as compared to equivalent JavaScript >> code is another instance of the Part I problem as it is caused by a call to >> `Native_Utils.eq` which is even less efficient than `Native_Utils.cmp` >> resulting in about a 1500% slowdown compared to JavaScript for the following >> code: >> >> import Bitwise as Bw >> >> testProg : Int -> Int >> testProg n = -- do some work >> let loop i = >> if Bw.and i 0x3FFFFFFF == 0x3FFFFFFF then i else >> loop (i + 1) in loop n >> >> which compiles to: >> >> var _user$project$Temp1482804013226255$testProg = function (n) { >> var loop = function (i) { >> loop: >> while (true) { >> if (_elm_lang$core$Native_Utils.eq(i & 1073741823, 1073741823)) { >> return i; >> } else { >> var _v0 = i + 1; >> i = _v0; >> continue loop; >> } >> } >> }; >> return loop(n); >> }; >> >> with `Native_Utils.eq` defined as: >> >> function eq(x, y) >> { >> var stack = []; >> var isEqual = eqHelp(x, y, 0, stack); >> var pair; >> while (isEqual && (pair = stack.pop())) >> { >> isEqual = eqHelp(pair.x, pair.y, 0, stack); >> } >> return isEqual; >> } >> >> >> function eqHelp(x, y, depth, stack) >> { >> if (depth > 100) >> { >> stack.push({ x: x, y: y }); >> return true; >> } >> >> if (x === y) >> { >> return true; >> } >> ... >> >> For this use case, there are a succession of conditions which won't cost >> that much as explained in the opening post, but it is twice as slow as the >> example in Part I because there are typically two nested calls of the >> functions `Native_Utils.eq` with `Native_Utils.eqHelp` called from within >> it! This is the reason it is twice as slow as the example in Part I. >> >> If and when the issue as of Part I is fixed, then bitwise operations will >> be fixed too. >> >> Meanwhile, for real work programs with intensive bitwise tight loop >> computations, Elm is likely up to about 10 times slower than JavaScript and >> for general numeric tight loop calculations about 5 times slower, which I >> find unacceptable. > > -- > 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. -- 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.
