Excellent points. I'll take a look at the links you posted. Maybe there's something in there I can't help but pursue :)
mandag 12. juni 2017 07.24.10 UTC+2 skrev Evan følgende: > > Oh, and a few more notes. I recently did two pull requests on a framework > comparison benchmark to improve the Elm implementation: > > - Start using lazy > <https://github.com/krausest/js-framework-benchmark/pull/192> - This > made the Elm version significantly faster than before. > - Get rid of List => Array => List conversion > <https://github.com/krausest/js-framework-benchmark/pull/194> - This > actually had *no significant impact* on the results. With random > noise, it actually got slower in the run they chose. Touching the DOM is > so > expensive that it tends to overshadow any other concern, and I had the > same > experience converting TodoMVC to use a Dict rather than List. > > In looking for these, I also found this PR > <https://github.com/krausest/js-framework-benchmark/pull/195> that does > another optimization which should help a bit. The fact that you can now > remove without changing event handlers in all subsequent entries should > provide a decent speed boost, but we'll see when the results are out! > > This is all to say: it is important to contextualize these ideas in the > performance characteristics of real programs, and those characteristics can > be quite surprising given how the DOM works. > > > On Monday, June 12, 2017 at 6:08:50 AM UTC+1, Evan wrote: >> >> Very interesting, thank you for sharing! >> >> I wanted to add a couple notes and ideas that I've had separately. >> >> >> Syntax >> >> I was formerly somewhat keen on having special syntax for other >> collections. For example, OCaml allows you to say [| 1, 2, 3 |] to create >> an array. Hassan made a really nice proposal >> <https://github.com/elm-lang/elm-plans/issues/12> to have it be #[ 1, 2, >> 3 ] back in 2015. Since then I realized you can do the following: >> >> a = Array.fromList >> s = Set.fromList >> d = Dict.fromList >> >> array = >> (a[ 1, 2, 3 ]) >> >> set = >> (s[ 1, 2, 3 ]) >> >> dict = >> (d[ 1 => "Tom", 2 => "Sue", 3 => "Jane" ]) >> >> (=>) = (,) >> >> This is 1 or 2 characters off all the proposals out there, and it is >> visually much nicer in my opinion. >> >> With that knowledge, the case for special syntax seems significantly >> weaker. I can also imagine detecting when a list is converted to something >> else and doing something more clever in the compiler. That path seems >> better overall to me. >> >> >> List performance of map, foldl, and foldr >> >> I shared this blog post >> <https://blogs.janestreet.com/optimizing-list-map/> about optimizing >> List.map in OCaml a while ago, and Fred did some excellent work on this >> <https://github.com/elm-lang/core/pull/707>! I have not had a chance to >> fully assess the impact on generated code size, so I have not merged it in >> yet. That trick can likely be very helpful for foldl and foldr, but no one >> has looked into it. >> >> I suspect there are many creative things we can do if some focused energy >> was applied to lists. I have not taken a comprehensive look at this after >> Elm got TCO, and I suspect we can do better! >> >> >> Alternate Implementations of List >> >> Another thing to consider before switching to some other data structure >> is that we can change the performance profile of List using various >> techniques behind the scenes. For example: >> >> - Skip Lists <https://en.wikipedia.org/wiki/Skip_list> >> - Finger Trees <https://en.wikipedia.org/wiki/Finger_tree> that maybe >> do some sort of "compression" on older leaves >> - I believe there's one that immutable.js does for their lists? >> Richard told me about something like this. Where "old" nodes grow >> exponentially in size so the nodes are 1, 2, 4, 8, etc. so it is faster >> to >> hop around and you get better locality. Do you recall what this was >> called >> Richard? >> >> I also think that manually recursing through lists with a case is >> relatively common, at least in my experience, so I think it'd be good to >> explore concrete bottlenecks in Elm code and see if there are not creative >> things we can do to improve the performance profile of List without >> changing it completely. >> >> >> Anyway, exciting to see your work as always! And hopefully these ideas >> are helpful! >> Evan >> >> >> >> On Monday, June 12, 2017 at 12:15:59 AM UTC+1, Robin Heggelund Hansen >> wrote: >>> >>> I've been doing some thinking on how to improve Arrays in Elm. The >>> result of that thinking have been written down in this document: >>> >>> >>> https://docs.google.com/document/d/1Z8IC5qk98ISQLP_xKXNOHScCfzkQ8jCVSiYd1SxObB4/edit?usp=sharing >>> >>> The document is quite large, but most of it are benchmark results >>> comparing Arrays and Lists. >>> >>> There are some questions at the bottom of the document that I would love >>> to get feedback on. >>> >> -- 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.
