jsperf | Run jsperf.com tests locally with your NodeJS version | Runtime Evironment library

You can use a simple set to group them by tag as follows:

(V8 developer here.)

The key point is that the implementation of Array.prototype.flat that you found is not at all optimized. As you observe, it follows the spec almost to the letter -- that's how you get an implementation that's correct but slow. (Actually the verdict on performance is not that simple: there are advantages to this implementation technique, like reliable performance from the first invocation, regardless of type feedback.)

Optimizing means adding additional fast paths that take various shortcuts when possible. That work hasn't been done yet for .flat(). It has been done for .concat(), for which V8 has a highly complex, super optimized implementation, which is why that approach is so stunningly fast.

The two handwritten methods you provided get to make assumptions that the generic .flat() has to check for (they know that they're iterating over arrays, they know that all elements are present, they know that the depth is 1), so they need to perform significantly fewer checks. Being JavaScript, they also (eventually) benefit from V8's optimizing compiler. (The fact that they get optimized after some time is part of the explanation why their performance appears somewhat variable at first; in a more robust test you could actually observe that effect quite clearly.)

All that said, in most real applications you probably won't notice a difference in practice: most applications don't spend their time flattening arrays with millions of elements, and for small arrays (tens, hundreds, or thousands of elements) the differences are below the noise level.

It depends.

To give an absolute answer, we would have to compile every piece of code / watch the interpreter on every possible browser / architecture combination. Then we could give an absolute answer which operation takes fewer processor cycles, everything else is pure speculation. And that's what I'm doing now:

The naive approach

Let's assume that engines do not perform any optimizations. That they just perform every step as defined in the specification. Then for every testcase the following happens:

typeof x === 'boolean'

(1) The type of x gets looked up. As the engine probably represents a generic "JavaScript Value" as a structure with a pointer to the actual data and an enum for the type of the value, getting a string describing the type is probably a lookup in a type -> type string map.

(2) Now we have two string values, that we have to compare ('boolean' === 'boolean'). First of all, it has to be checked that the types equal. That is probably done by comparing the type field of both values, and a bitwise equality (meaning: one processor op).

(3) Finally the value has to be compared for equality. For strings this means iterating over both strings and comparing the characters to each other.

x === true || x === false

(1) First of all, the types of x and true and x ad false have to be compared as described above.

(2) Secondly the values have to be compared, for booleans that's bitwise quality (meaning: one processor op).

(3) The last step is the or expression. Given two values, they first have to be checked for truthiness (which is quite easy for booleans, but still we have to check again that these are really booleans), then the or operation can be done (bitwise or, meaning: one processor op).

So which one is faster? If I had to guess, the second approach, as the first one has to do string equality, which probably takes a few iterations more.

The optimal approach

A very clever compiler might realize that typeof x === 'boolean' is only true if the type of x is boolean. SO it could be optimized to (C++ pseudocode):

try/catch idiom works very well when you have fully synchronous code, but asynchronous operations render it useless, no errors will be caught. i.e., the function will begin its course while the outer stack runs through and gets to the last line without any errors. If an error occurs at some point in the future inside asynchronous function – nothing will be caught.

When we use Promises, “we’ve lost our error handling”, you might say. That’s right, we don’t need to do anything special here to propagate error because we return a promise and there’s built in support for error flow.

I believe what's happening in the Chrome and Firefox case is that it's inlining the mathAdd function. Because it's a simple function with no side effects that is both created and called within the function, the compiler replaces the call site with the internal code of the function.

The resulting code will look like this:

V8 developer here. As wOxxOm points out, this is mostly an illustration of the pitfalls of microbenchmarking.

First off:

Unexpected de-optimisation...

Nope, deoptimization is not the issue here (it's a very specific term with a very specific meaning). You mean "slowdown".

...on high-iteration count

Nope, high iteration count is also not the issue here. While you could say that the lack of warmup in your test is contributing to the results you see, that contribution is the part you found less surprising.

One mechanism to be aware of is "on-stack replacement": functions with (very) long-running loops will get optimized while the loop is executing. It doesn't make sense to do that on a background thread, so execution is interrupted while optimization happens on the main thread. If the code after the loop hasn't been executed yet and therefore doesn't have type feedback, then the optimized code will be thrown away ("deoptimized") once execution reaches the end of the loop, to collect type feedback while executing unoptimized bytecode. In case of another long-running loop like in the example here, the same OSR-then-deopt dance will be repeated. That means some nontrivial fraction of what you're measuring is optimization time. This explains most of the variance you see in runRawRandom before times stabilize.

Another effect to be aware of is inlining. The smaller and faster the function in question, the bigger the call overhead, which is avoided when you write the benchmark such that the function can get inlined. Additionally, inlining often unlocks additional optimization opportunities: in this case, the compiler can see after inlining that the comparison result is never used, so it dead-code-eliminates all the comparisons. This explains why runRandomLooped is so much slower than runRawRandom: the latter benchmarks empty loops. The former's very first iteration is "fast" (=empty) because V8 at that point inlines mathCompare for the f(...) call in jsPerfRandom (because that's the only function it's ever seen there), but soon after it realizes "whoops, various different functions are getting called here", so it deopts and won't try to inline again on subsequent optimization attempts.

If you care about the details, you can use some combination of the flags --trace-opt --trace-deopt --trace-osr --trace-turbo-inlining --print-opt-code --code-comments to investigate the behavior in depth. Be warned though that while this exercise is likely going to cost you significant time, what you can learn from the behavior of a microbenchmark is, in all likelihood, not going to be relevant for real-world use cases.

To illustrate:

• you have one microbenchmark here that proves beyond doubt that mathCompare is much slower than logicCompare
• you have another microbenchmark that proves beyond doubt that both have the same performance
• your aggregate observations prove beyond doubt that performance goes down when V8 decides to optimize things

In practice though, all three observations are false (which is not overly surprising given that two of them are direct contradictions of each other):

• the "fast results" are not reflective of real-world behavior because they could dead-code eliminate the workload you were trying to measure
• the "slow results" are not reflective of real-world behavior because the specific way the benchmark was written prevented inlining of a tiny function (which would virtually always get inlined in real code)
• the supposed "performance going down" was just a microbenchmarking artifact, and was not at all due to failed/useless optimizations, and would not occur in a real-world situation.

March 2019 Update: results are inconsistent between Firefox and Chrome - perf.zone behave anomalously on Chrome, jsben.ch behaves anomalously on Firefox. Until we know exactly why the best you can do is benchmark on multiple websites (but I'd still skip jsben.ch, the others give you a least some error margin and stats on how many runs were taken, and so on)

TL;DR: running your code on perf.zone and on jsbench.github.io (see here and here), the results closely match jsperf. Personally, and for other reasons than just these results, I trust these three websites more than jsben.ch.

Recently, I tried benchmarking the performance of string concatenation too, but in my case it's building one string out of 1000000+ single character strings (join('') wins for numbers this large and up, btw). On my machine the jsben.ch timed out instead of giving a result at all. Perhaps it works better on yours, but for me that's a big warning sign:

http://jsben.ch/mYaJk

http://jsbench.github.io/#26d1f3705b3340ace36cbad7b24055fb

https://run.perf.zone/view/join-vs-concat-when-dealing-with-very-long-lists-of-single-character-strings-1512490506658

(I can't be bothered to ever have to deal with jsperf's not all tests inserted again, sorry)

At the moment I suspect but can't prove that perf.zone has slightly more reliable benchmark numbers:

• when optimising lz-string I used jsbench.github.io for a very long time, but at some point I noticed there were impossibly large error margins for certain types of code, over 100%.

• running benchmarks on mobile is fine with jsperf.com and perf.zone, but jsbench.github.io is kinda janky and the CSS breaks while running tests.

Perhaps these two things are related: perhaps the method that jsbench.github.io uses to update the DOM introduces some kind of overhead that affects the benchmarks (they should meta-benchmark that...).

Note: perf.zone is not without its flaws. It sometimes times out when trying to save a benchmark (the worst time to do so...) and you can only fork your own code, not edit it. But the output still seems to be more in line with jsperf, and it has a really nice "quick" mode for throwaway benchmarking

As it turned out, there are two Babel plugins available that do the job quite well.

• @babel/plugin-transform-for-of transpiles for of loops to index based loops

• babel-plugin-loop-optimizer transpiles .forEach, .every, .find, .map, .filter statements to index based for loops

In my configuration, I use Webpack and ts-loader to transpile TypeScript. To use these Babel plugins while keeping the ts-loader I chain the two loaders, thus Babel plugins will optimize the js code that comes out of ts-loader.

webpack.config.js: