Note that a high quality optimizing compiler like BuckleScript outperforms native JS significantly > Elm. (See the benchmark here: http://bloomberg.github.io/bucklescript/slides/preview/bb-reveal-example-presentation.html#/5/1 )
On Sun, Jan 1, 2017 at 9:48 AM, GordonBGood <[email protected]> wrote: > On Wednesday, 28 December 2016 21:23:19 UTC+7, Peter Damoc wrote: >> >> >> >> On Wed, Dec 28, 2016 at 3:10 PM, GordonBGood <[email protected]> wrote: >> >>> >>> So you are saying we can already do the following: >>> >>> type Msg = ProgProgress Progress | ProgCancelled | ProgDone Answer | Tick >>> >>> port startLRP : () -> Cmd msg >>> >>> port cancelLRP : () -> Cmd msg >>> >>> subscriptions model = >>> Subs.batch >>> [ lrpProgress ProgProgress >>> , lrpCancelled ProgCancelled >>> , lrpDone ProgDone >>> , Timer.every 1000 Tick ] >>> >>> port lrpProgress : (Progress -> Msg) -> Sub Msg >>> >>> port lrpCancelled : (() -> Msg) -> Sub Msg >>> >>> port lrpDone : (Answer -> Msg) -> Sub Msg >>> >>> with the Native JavaScript as per the link for each of the ports, Types >>> all defined, update function handling all Msg cases, and the subscription >>> system will automatically handle getting each subscription to the right Msg? >>> >>> Will this not cause problems with the Timer.every subscription? >>> >>> >> This looks like valid code to me. >> I would implement it differently, in a way where the model captures the >> current state of the process and the subscription uses that state to listen >> only to the relevant Subs but... that's more of an optimization. >> > > I would implement it differently too, but this was just for a quick > example. > > >> Also, I assume that Answer and Progress are aliases to types that can >> travel the ports. >> > > Of course, didn't want to pin them to specify types whether they be Int, > Float, Record, Union, Tagged Union, Array, or whatever, is immaterial. > > What kind of problems do you foresee with Timer.every? >> > > That's why I added it as I was concerned that using some Sub's with event > managers and some without would somehow mix up the system. I've now tested > this (got sidetracked by looking for something good to write the fast bits > that isn't JavaScript or even TypeScript as you can see in the latter part > of the thread), and it works exactly as advertised, so no worries. I guess > my take away on Event/effect (defined in `effect` modules) managers is that > they are required when there is a possibility that the same Sub would be > used for more than one Msg, possibly of different kinds; as long as one can > write code, as here or even a little more complex as you are suggesting, > then they are not required, and as they only are fired for the specific > Subs for which they are defined but work behind=the=scenes, then their > application doesn't need to be concerned their implimentation. > > That leaves me impressed with the ease-of-use for Elm, with my biggest > wish list items are all concerned with making Elm faster as is the subject > of the thread; but it is still early days for optimization of the language > as long as it is still evolving. > > As raised in the opening post, the main concern is nested function calls > as is a common bottleneck with functional languages, which is usually > addressed with inlining functions where possible and specializations and > rules defining when this can be used, also using compiler magic to not use > functions at all when not necessary (as has been already done for Records, > and commonly used Tuples, which is why these are not created with library > functions). I note that the current 0l18 compiler already does quite a lot > in inlining of native functions/operators (except for comparison, which is > the optenint post's concern) > > A more minor issue is the way immutability has been implemented in the > existing libraries, especially the Array library: So much attention has > been paid to making the `set` function have a better big O performance that > it has built up a considerably large constant overhead in all Array > operations so that these are too slow to use for anything serious. A > better approach is the Haskell one for immutable arrays where they would be > standard JSArrays (in this context) treated immutably without an equivalent > to the`set` function at all and where all transmuting of arrays is handled > by transmuting functions working on the whole array. In Haskell the > transmuting functions are based on (relatively efficient) lazy lists which > thus avoid excessive memory use, but I am suggesting that in Elm they would > be based on passed-in functions where the new temporarily mutable array is > an argument whose type cannot be created in Elm code but can only exist > when passed into the context of these transmuting functions as an argument; > then, in order to get speed, one would not work by setting array elements > individually, but would try to minimize the creation of many new immutable > arrays by the function that was passed into the creation function in the > first place. However, as library concerns, this can easily;be fixed later, > and if necessary in the interim, it wouldn't be too hard to create the > required libraries. > > The only reason that I suggest these things is that I agree with Evan that > JavaScript would ideally only be used as necessary in libraries, with the > majority of applications never having to deal with it; however, with the > current version there seems to be various applications where Elm code is > not performant enough. > > -- > 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. > -- Regards -- Hongbo Zhang -- 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.
