On Wednesday, 28 December 2016 10:59:39 UTC+7, Robin Heggelund Hansen wrote: > > I'm not saying that performance of tight loops aren't important, what I'm > questioning is how much comparison and equality operators affect them. I > would assume that higher-order functions and immutability has a much bigger > impact on tight loops in games, graphics and intensive math applications. >
As to less speed from Higher Order Functions, you are right that these are slow due to (often nested) function calls, but just as for other languages one doesn't have to use them for time critical inner loops especially since tail call recursion optimization within the same function now works. You are right (again) that immutability has a great effect on the speed of these types of applications, but immutable data structures are implemented as libraries that can be improved so that this exterior immutability may not be a bottleneck. For instance, many such applications are going to need fast Array's, for which the current immutable Array library is far from ideal. Haskell takes care of this by providing state monads that allow mutability whilst threading the state monad through the mutating code. I am not suggesting that Elm needs the complexity of full monads, but must of the needs for mutability could be handled in the creation of the immutable data structures. Thus, addition of the equivalent to Haskell's accumArray`, `accum`, and (//)` to the Elm Array library could make Array operations for many of these much faster. In Haskell, these take a (lazy) list of `(index, value)` pairs as an argument which wouldn't be very efficient with Elm's (non-lazy) lists, but providing in-line functions that work mutably only inside these Array create/update routines wouldn't be that hard. Elm's record updates work on that principle already: mutating a copy of the record only when the new (immutable) copy is created - in effect making the assignment operator mutable only inside the update. Alternately and even simpler syntactically would be using a very efficient version of a lazy list and direct translations of the Haskell functions, but that wouldn't be as fast as it would require at least one function call and tuple destructure per array element modified. There are other bottlenecks: array bounds checks and so on, but eventually the Elm compiler might get smart enough to recognize when these are inherent to the code as other languages do. Even if not optimized away, as seen in the examples here conditional code is a minor overhead on a modern CPU as compared to function calls. For its many benefits, I would accept Elm code that is up to twice as slow as raw JavaScript, but not more than that. I believe that it is possible to somewhat achieve better than that while retaining all of Elm'g design goals through compiler/library improvements -- 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.
