Elm TCO is js perf

[Laszlo Pandy]

Please run these two jsperfs in all the browsers that you have:
http://jsperf.com/elm-tco-1
http://jsperf.com/elm-tco-2a

I would like to collect data about which is faster.

The first one tests the different between Elm.List.Native.foldl (hand written JS) and foldl written in Elm (and compiled with TCO).

The second link tests implementing map with foldl + reverse (instead of foldr, because foldr is not tail recursive). Here hand written code might have an advantage because it can use a temporary array, whereas foldl + reverse create an extra list which requires more use of cons.

[Joey Eremondi]

It's worth mentioning that these are both included in the current benchmark suite. It's still worth testing them on their own: Evan though that maybe having toArray used so much put it on a fast path of some sort.

--
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 elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Laszlo Pandy]

So it seems like the foldl + reverse is always slower except in Firefox for some reason.

Probably it's better to keep using the native way because using reverse has the potential to create a lot of garbage for the GC.

However Joey's comment about toArray fast path gave me an idea: what if we store a new property on Nil and Cons: _length. Then we can do new Array(xs._length), which preallocates the array's memory at the correct length. According to JS perf it's about 40% faster than letting the array grow, and it would let List.length be O(1) (currently it's O(n)).

[Jeff Smits]

If you want to invest in using Native list iteration, you might switch the Native representation to JS lists as well. The same happened with Strings, and worked out well.

[Joey Eremondi]

Interesting results: I get TCO being faster on FireFox.

On MS Edge, I get Native faster for test 1, no difference on test 2 (i.e. equal within margin of error).

On Chrome, test 1 is no difference, and test 2 faster with Native.

Honestly, the benefits we get from simplicity, allowing (future) optimizations like inlining and DCE, it's probably worth it to switch to an Elm implementation.

It's pretty well known that foldl is tail-recursive, so I think it's fair to tell people "if you need tail recursion, use foldl".

[Rick Richardson]

On x64 Linux, Chrome  test 1:  Elm impl is 7% faster.   test2 : they are the same. 

[Rick Richardson]

Sorry, I misread the results.  Test2,  Elm TCO is 34% slower. 

[Richard Feldman]

Here's what I ran.

2011 i7 MacBook Air:
- Chrome 45
- Chrome 44
- Firefox 40
- Safari 8

2011 i7 MacBook Air via VirtualBox VM:
- IE11
- IE9

Samsung Galaxy S6 phone:
- Mobile Chrome
- Android Browser