In January, I published an article on RisingStack’s blog
Now it is time for a follow-up article regarding the sources of performance bottlenecks in Node.js.
The following table states for each pattern if it can be optimized on different versions of Node.js.
|access non-existent index of `arguments`||no||no||no||no||no|
|`for…in` loop whose key exists in outer scope||no||no||no||no||no|
|leaks `arguments` via a closure||no||no||no||no||no|
|object literal containing a getter||no||no||no||no||no|
|object literal containing a setter||no||no||no||no||no|
|overwrite named function argument and read `arguments`||no||no||no||no||no|
|pass `arguments` to `call()`||no||no||no||no||no|
|Unsupported phi use of arguments||no||no||no||no||no|
|Unsupported phi use of const or let variable||no||no||no||no||no|
|assign to `arguments`||no||no||no||no||yes|
|function is bound using `Function.prototype.bind()`||no||no||yes||yes||yes|
|`for…in` loop using an array||no||yes||yes||yes||yes|
|`switch` statement with over 128 cases||no||yes||yes||yes||yes|
As you can see, some patterns are not optimization killers in all Node.js versions.
This table has been built using a very handy repository by Colin Ihrig
. I forked it
to add some patterns and to change the output format. Some results (for instance, the patterns optimized by TurboFan) had to be computed using directly the
In the rest of this article, we will go through the different patterns considered in this table.
For each pattern present in the table, we will give:
- A code example
- A short description of the language feature/pattern that explains (when possible) why it prevents V8 from optimizing it.
were introduced in the ECMAScript 2015 norm. This pattern is mainly a helper for the
object. It introduces a lot of polymorphism in the signature of the function.
At the moment, V8 does not optimize methods that use this feature.
access non-existent index of `arguments`
was introduced in the first version of ECMAScript. Using it adds polymorphism into the function’s signature.
As far as I know, only two uses of
are not performance killers in V8.
statement was introduced formally in the third version of the ECMAScript norm. Using it will potentially change the execution workflow of the script.
Optimizing a function containing such statement looks extremely complex. Anyway, there should not be any
statement in production code.
`for…in` loop whose key exists in outer scope
loops gave a serious headache to the V8 team. Since they wrote on this topic, I think it is best to let them expose this topic: Fast For-In in V8 (on V8 Blog)
leaks `arguments` via a closure
was introduced in the first version of ECMAScript. Using it introduces polymorphism into the function’s signature.
The Bluebird wiki has a very nice paragraph
object literal containing a getter and object literal containing a setter
ECMAScript offers a powerful way to execute code when (read or write) access to an object’s property is made. However, it introduces a possible polymorphism in the typing of the members of an object.
overwrite named function argument and read `arguments`
Once again, this one is about the use of
. V8 does not like when you mess with arguments.
pass `arguments` to `call()`
You might want to pass the arguments of a function from a method to another. In this case, you should never use
accepts an Array-like object as the second argument, you can pass the
object directly to it:
Unsupported phi use of arguments and Unsupported phi use of const or let variable
Those two are still a bit obscure to me. You can find some documentation on them on the v8 bailout reasons repository
This is what is called an arguments leak. It is impossible to make safe heuristics regarding the signature of such a function. Therefore, its optimization is extremely unlikely.
have been introduced in the ECMAScript 2016 norm. Those objects have an unusual behavior for V8 since these functions can be exited and re-entered.
At the moment, V8 does not optimize generators.
assign to `arguments`
Historically, this pattern was not optimized and, as often, this is due to the use of the
However, it seems that latest versions of the engine optimize it.
Historically, this pattern was not optimized.
Despites its unstable nature, it seems that latest versions of the engine optimize it thanks to its new architecture: TurboFan.
`try…catch…finally` statement, `try…finally` statement and `try…catch` statement
This is probably the coolest everyday-life enhancement in V8. It is possible thanks to TurboFan which is the new optimizing compiler
function is bound using `Function.prototype.bind()`
has been introduced in the 5.1 version of ECMAScript. It is used to create a new function from another by binding a context (
and arguments) to another function.
Benedikt Meurer has written an article
on this topic; it is a short and high-quality reading.
`for…in` loop using an array
As stated before,
loops have been an issue for the V8 team. Once again, I advise reading their blog post
on this topic.
`switch` statement with over 128 cases
The real code is available in another gist
statements were not optimized. But the V8 team removed this constraint a while ago.
What about other JS engines?
I am currently going through the documentation of ChakraCore Node.js
version. This will probably result in another article on the topic.
Regarding other engines, I will wait to see the results of the VM Working Group
and I will try to cover as many Node.js versions as possible.
A few last words
Please let me know if you have any comments or remarks regarding this article. I am easily reachable on Twitter
Also, don’t hesitate to give
a try to detect users performing attacks in your app and block targeted attacks. ��