On Sunday, 15 January 2017 11:56:18 UTC+7, Bob Zhang wrote: > > I would be very surprised if parsing is the bottle neck > In most cases, type checking and register allocations (could be quadratic) > takes much more time. OCaml's type checking algorithms is very clever, > almost linear in most practical use cases. >
Yet Evan did some relatively minor changes to parsing which is said to have over doubled compilation speed. If parsing is usually a minor part, that would seem to say that the other parts are even faster. It would seem that Elm does all of its type checking in the front end and almost nothing is done with types in the code generation. Elm basically has fixed types, as even the "type" keyword can only currently be used to define variations of tagged unions although such new types can be nested to any level, and if nested deeply I suppose could take a large amount of time to type check the structure if not done cleverly. I don't want to dig into the front end too much other than to try to nail down any problems as I think it is beyond my capabilities, but I plan to look into the code generator in more depth this next week. Much of my experience is dealing with low level code. > On Sat, Jan 14, 2017 at 11:14 PM Richard Feldman <[email protected] > <javascript:>> wrote: > >> I'm wondering why the Elm compiler is so slow at parsing if that is where >>>>> the slow-down is >>>>> >>>> >>>> Evan recently rewrote the parser to be much faster. >>>> >>>> You can try a preview binary >>>> <https://groups.google.com/forum/#!searchin/elm-dev/parser%7Csort:relevance/elm-dev/c_BDwK5UXFs/zP9aRkMeEQAJ> >>>> >>>> of the new version if you're curious. :) >>>> >>> -- 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.
