proposal-flatMap | proposal for flatten and flatMap on arrays | Functional Programming library

This gist is a small benchmark I wrote comparing the performance for 4 alternatives for flattening arrays of depth=1 in JS (the code can be copied as-is into the google console). If I'm not missing anything, the native Array.prototype.flat has the worst performance by far - on the order of 30-50 times slower than any of the alternatives.

Update: I've created a benchmark on jsperf.

It should be noted that the 4th implementation in this benchmark is consistently the most performant - often achieving a performance that is 70 times better. The code was tested several times in node v12 and the Chrome console.

This result is accentuated most in a large subset - see the last 2 arrays tested below. This result is very surprising, given the spec, and the V8 implementation which seems to follow the spec by the letter. My C++ knowledge is non-existent, as is my familiarity with the V8 rabbit hole, but it seems to me that given the recursive definition, once we reach a final depth subarray, no further recursive calls are made for that subarray call (the flag shouldFlatten is false when the decremented depth reaches 0, i.e., the final sub-level) and adding to the flattened result includes iterative looping over each sub-element, and a simple call to this method. Therefore, I cannot see a good reason why a.flat should suffer so much on performance.

I thought perhaps the fact that in the native flat the result's size isn't pre-allocated might explain the difference. The second implementation in this benchmark, which isn't pre-allocated, shows that this alone cannot explain the difference - it is still 5-10 times more performant than the native flat. What could be the reason for this?

Implementations tested (order is the same in code, stored in the implementations array - the two I wrote are at the end of code snippet):

1. My own flattening implementation that includes pre-allocating the final flattened length (thus avoiding size all re-allocations). Excuse the imperative style code, I was going for max performance.
2. Simplest naive implementation, looping over each sub-array and pushing into the final array. (thus risking many size re-allocations).
3. Array.prototype.flat (native flat)
4. [ ].concat(...arr) (=spreading array, then concatenating the results together. This is a popular way of accomplishing a depth=1 flattening).

Arrays tested (order is the same in code, stored in the benchmarks object):

1. 1000 subarrays with 10 elements each. (10 thou total)
2. 10 subarrays with 1000 elements each. (10 thou total)
3. 10000 subarrays with 1000 elements each. (10 mil total)
4. 100 subarrays with 100000 elements each. (10 mil total)