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.

Reply via email to