Unhappy with the speed of javascripts? - Wait a year and a half, and it will pass!

I remind you (because it was probably forgotten) that on May 22, 2012 I experimented with reading the headers of the Fidonet echo-mail (stored in the JAM format) using my own module composed for Node.js (based on the turned-up jParser engine, the documentation of which was translated a little earlier )

Then, running a test reading on a single-core Pentium IV (2.2 GHz), I remained dissatisfied with the speed: it took three to four seconds to read 8222 headers from the archive of just one echo conference, which has been going on since March 2007.

This week my hands reached the source code of that module again; and I started by transferring the previous test to the Mocha engineand transferred the testing to the Travis CI server , indicating in the .travis.yml file such settings that would ensure testing on three consecutive versions of the Node.js engine - at 0.6, at 0.8 and at 0.10.

It turned out that the difference in speed is visible to the naked eye:

• On the Node engine version 0.6.21, the test ran 3145 milliseconds.
   
• On the Node engine version 0.8.25, the test worked for 2211 milliseconds.
   
• On the Node engine version 0.10.12, the test worked 1006 milliseconds.

When looking at these results, at first it is tempting to see an arithmetic progression (three seconds → two seconds → one second) with the obvious conclusion that in the next version of the Node engine the test will start working instantly.

In fact, of course, the result only indicates that in Node version 0.8 the test works about one and a half times faster than in the previous version (0.6), and in Node version 0.10 - even two times faster than in the previous ( 0.8).

But even that is not bad.

In addition, this spring I bought myself a newer computer based on the quad-core i7-3770 processor ,and on it the same test takes even less time - it is closer to half a second than to a whole second:



It’s understandable: after all , Travis uses virtual machines, but I’m real.

The totality of the above observations allows us to confidently and joyfully say that Node.js is accelerating sharply from version to version (probably due to the increased speed of the V8 engine, on which Node is based), and in combination with the increase in computer performance, this allows us to adhere to Expectant tactics that I put in the headline.

You can also spend your time optimizing the work of your javascripts, but only if there is nothing more to seriously improve them, and only if you are confident that you will show a comparable result (acceleration by a half to two timesfor half a year or a year), and not even for end users, a slight acceleration of the script will still remain invisible against the background of a sharp acceleration of the engine over the same time.