Interesting results, thanks for sharing. I can perhaps shed some light on the performance differences.<p>> Buffer 4.259 5.006<p>In v0.10, buffers are sliced off from big chunks of pre-allocated memory. It makes allocating buffers a little cheaper but because each buffer maintains a back pointer to the backing memory, that memory isn't reclaimed until the last buffer is garbage collected.<p>Buffers in node.js v0.11 and io.js v1.x instead own their memory. It reduces peak memory (because memory is no longer allocated in big chunks) and removes a whole class of accidental memory leaks.<p>That said, the fact that it's sometimes slower is definitely something to look into.<p>> Typed-Array 4.944 11.555<p>Typed arrays in v0.10 are a homegrown and non-conforming implementation.<p>Node.js v0.11 and io.js v1.x use V8's native typed arrays, which are indeed slower at this point. I know the V8 people are working on them, it's probably just a matter of time - although more eyeballs certainly won't hurt.<p>> Regular Array 40.416 7.359<p>Full credit goes to the V8 team for that one. :-)
There are two very good comments at the bottom of the article. Here for your consumption:<p>Author: (Unknown)
2015-01-19 12:54 UTC<p>io.js based on node v0.11, so you need compare<p>- v0.10 (nodejs)- v0.11 (nodejs)
- v0.11 (nodejs)- v1.0 (iojs)<p>Author: Michael Schöbel
2015-01-19 13:01 UTC<p>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.<p>But most people won't compile themselves. Most will use the latest stable release.
Reporting benchmark results on a single OS, on a single CPU type isn't really benchmarking. It's an isolated case of results.<p>I'd recommend to perform an accurate suite of performance tests, use different OS (CoreOS, Ubuntu) that are actually used in server environments. Also different machine hardware will play a role.<p>There's not enough data at this point to come to any conclusion at this point imo.<p>This result set is like saying that 95% of the people on the web use the safari browser on the Apple website.
> This can be extremely important if you have a project with heavy CPU-use<p>Would you recommend using something different than JavaScript when writing CPU heavy apps? I was under the impression that it's better suited when dealing with high I/O.
On a slight tangent, there's an article using the Sieve of Eratosthenes demonstrating the use of Communicating Sequential Threads (CSP) on Russ Cox' website (one of the developers of Go)<p><a href="http://swtch.com/~rsc/thread/" rel="nofollow">http://swtch.com/~rsc/thread/</a>
These are very interesting findings. On a higher level though: Are there any significant performance differences between the APIs of node and io? E.g. tcp package processing, file system access etc? I know that a lot of them are effectively C, so independent of the V8 version.
> Depending on what your Node application does, my
> findings may or may not apply to your use-case.<p>I'm going to go out on a limb and say that the proportion of real world Node apps that will be noticably affected by this is less than 1%
The competition between these teams is going to make both of them better. They will not only be competing on speed, but also on features. A huge win for developers.