This site uses 3rd-party cookies for targeted advertising. If you do not agree to this, then please leave this site now. Otherwise please click on "Ok" to continue.

Node.js and io.js - Very different in performance


tl;dr - Depending on whether you use Node.js or io.js, you may experience performance differ by a factor of more than 5 for identical code.

[Update 21-Jan-2015: There is now a new blogpost that compares Node.js 0.11.15 and io.js 1.0.3. It also gives additional data and an explanation why io.js 1.0.2 performs so poorly in one of the tests here.]

First of all, let me make something clear. This is not, and cannot be, a comprehensive test. Every application is different. Depending on what your Node application does, my findings may or may not apply to your use-case.

What I tested

In a previous article I tested the performance of a very simple algorithm for finding prime-numbers, the Sieve of Eratosthenes, in C, Java, JavaScript and FreePascal. To test JavaScript I used Node and chose three different ways of implementing this algorithm, using a regular array, typed-array or buffer.

Today I want to use the same benchmark to show how much performance can vary between Node.js and io.js. For those of you who don't know it yet, io.js is a fork of Node.

I will use the same code as in my previous article. You can find it at the end of that article.

Node and io.js have one important thing in common. They both rely on Chrome's V8 JavaScript Engine. But they use different versions of V8. So when I'm comparing Node and io.js, I'm actually comparing the different versions of Chrome's V8 JavaScript Engine they use.

For my previous test I used Node 0.10.32 as that is the one that comes with OpenSuse 13.2, the Linux distribution that I'm using. But for today's test I will use Node 0.10.35 and io.js 1.0.2 as these are the latest available releases. And yes, I am aware that io.js describes that release as "unstable". But it's all I've got. :)

Just as I did for my previous article, I ran each test 7 times and then used the median time as my result. I was running the tests on an Intel i7-4771 3,5GHz using a 64-bit OpenSuse 13.2.

Here are the results:

Node.js 0.10.35 io.js 1.0.2
Buffer 4.259 5.006
Typed-Array 4.944 11.555
Regular Array 40.416 7.359
(Times are listed in seconds)

As you can see, the performance for typed-array and regular array varies quite dramatically.

Using a buffer, io.js takes almost 18% longer than Node. Not nice to see, but not something to really worry about.

The typed-array test takes more than twice as long with io.js than with Node. Now that is a pretty significant difference.

But with regular arrays it is the other way around, and even more pronounced. Here Node takes more than 5x as long as io.js.

I must say that I'm quite disturbed by how much performance can differ. For such a mature product, the V8 JavaScript Engine shows way too much variation in performance between versions. I could live with that if performance would always increase with each version. But the data clearly shows that it can go either way. And that should not happen.


There is no clear winner. Sometimes Node is faster and sometimes io.js is. Also keep in mind that this test is far from anything you would do in real-life.

Even different versions of Node can behave differently in my experience. I remember that there was a regression with a development-version of Node which caused slow performance with buffers. See this issue on GitHub.

This can be extremely important if you have a project with heavy CPU-use and which scales to several servers on something like AWS or Azure. You could potentially be wasting a lot of money if your application performs poorly with the version of Node/io.js that you use. You could be needing more servers than necessary because of that.

If you take only one piece of information from this article, then let it be to always remember to test how your code performs with different versions of Node/io.js.


Author: (Unknown)
2015-01-19 12:36 UTC

The newer version of v8 optimises performance for regular arrays?

Author: Michael Schöbel
2015-01-19 12:38 UTC

I don't know. I don't have that in-depth knowledge of V8. I just saw the results. The "why", I don't know.

Author: (Unknown)
2015-01-19 12:54 UTC

io.js based on node v0.11, so you need compare

- v0.10 (nodejs)- v0.11 (nodejs)
- v0.11 (nodejs)- v1.0 (iojs)

Author: Michael Schöbel
2015-01-19 13:01 UTC

I also downloaded sources and compiled the latest master branch of Node yesterday evening. Performance was within 2% of io.js for all three tests.

But most people won't compile themselves. Most will use the latest stable release.

Author: (Unknown)
2015-01-19 13:20 UTC

Was the sieve running under a seperate worker process?

Author: Michael Schöbel
2015-01-19 13:26 UTC

No. Single process.

Author: (Unknown)
2015-01-19 13:41 UTC

Would be lovely to see also performance of transient from mori.js library for that problem.

Author: Michael Schöbel
2015-01-19 13:51 UTC

Sorry, but until you mentioned mori.js, I hadn't even heard of it.

Im still pretty new to JavaScript and Node...

Author: (Unknown)
2015-01-19 14:45 UTC

"For such a mature product, the V8 JavaScript Engine shows way too much variation in performance between versions"

It's the JIT compiler. Get used to it, because it's not likely to change.

Author: (Unknown)
2015-01-19 14:58 UTC

When you say 'Performance was within 2% of io.js for all three tests.', in your comment, do you mean, it was with 2% of your previous findings, or that the difference between them has closed from as high as 500%, down to 2%?

Author: Michael Schöbel
2015-01-19 15:01 UTC

Performance of Node's master branch was within 2% of what I measured for io.js 1.0.2.

So almost no difference between the current io.js and Node's master branch.

Author: (Unknown)
2015-01-19 15:37 UTC

If you're writing CPU-bound code in Node.js, do the following:

1) Recheck your algorithms, and see if you can use more efficient ones.

2) Switch to a different language designed for speed, possibly Rust or Julia.

Configuring which version of Node/IO.js you're running just sounds like the wrong thing to be messing around with.

Author: (Unknown)
2015-01-19 15:58 UTC

you could also use Go and perform 100x times better than Node or io.js and look like a modern hipster

Author: (Unknown)
2015-01-19 17:32 UTC

This is because what you're really testing is NodeJS's typed array implementation vs V8's.

Author: (Unknown)
2015-01-19 19:40 UTC

the timing by seconds may be less instructional then user ticks.

like weighing the atoms, testing in large volume may indicate better average.

Author: (Unknown)
2015-01-20 08:10 UTC

This is off-topic, but your site is hard to read (and a little ugly) on anything other than Mac OS X - I presume you're using that? MacOS has a known quirk in it's font-smoothing that renders fonts with extra weight, such that light-fonts appear heavier (see e.g. It's a bit of a shame to deemphasize otherwise fine content due to such usability issues.

Author: Michael Schöbel
2015-01-20 09:05 UTC

Actually MacOS is the one OS that I haven't used to look at my site. And it looks fine to me. Granted, the webdesign could be better... :)

I have tested with Linux (OpenSuse 13.2), Windows 7 and 8.1, and with an iPad.

Author: (Unknown)
2015-01-20 14:08 UTC

Heh makes sense. You're hosting on Windows/IIS 8.0

Author: (Unknown)
2015-01-22 15:19 UTC

I had no problem reading the site, if that helps :)

Author: (Unknown)
2015-01-22 22:52 UTC

Could be that this has something to do with the V8 "deoptimization changes" I've been hearing about...?!

Author: (Unknown)
2015-02-17 03:53 UTC

It's funny to compare Node.js and io.js using CPU bound test. If you really need to have a CPU bound application, please write them in C, and call them using Node.js.

Also, again, I am sorry, I have a bad feeling toward io.js.

ES6 syntax is not an appealing reason to use io.js. io.js is just some guys who need a toy to play... however, we need to have production ready solution to make money. and I am sorry, ES6 harmony will bring disaster to javascript.

I see this happened in PHP and Actionscript. Just don't understand why these stupid things happened again.

For example, Harmony modules is a stupid design. too verbose. Harmony class just provide you another way of prototype inheritance. It sounds good because you will have more choices initially.

However, the same things happened in php and action script already. Till the end, the new learner will be confused by different ways to do the same thing. In addition, it will be more complicated between different projects to co-work. Some guys want to use ES6 modules, some guys want to use Node.js commonjs modules....and some guys want to use ES6 class....

The standard is not consistent anymore...

ES6 sucks!! and I will hear people someday in the future saying something like today PHP or AS3 programmers said... It's too complicated for the new learners to learn it.

I will stay and watch io.js. However, I have no interest to play it, because I don't need toy. I need something which can help me to make money. If io.js win, yes, I'll use io.js, or maybe it is good to see some guys who leave node.js community to play their toy, and make node.js better without them.

You want to comment on this blog-post? If yes, then simply enter your comment in the field below and click on "Submit".

Comments are moderated at the moment thanks to some $%&# who thought it would be funny to post total nonsense here.


Back to the Homepage

A Programmer's Diary