Rejecting jParser (in favor of working directly with Node.js buffers) speeds up the script by an order of magnitude

Turn over several pages of the recent past.

On May 16, 2012, RReverser in the Javascript BMP Parser blog spoke about the use of the jParser module for analyzing binary data in the browser.

The next day (May 17, 2012) in the jParser: Binary File Analysis Works Simply , I translated the jParser documentation, and a little later (on May 22, 2012, in the Node.js blog on Fidonet: we read javascript echomail headers, stored in the JAM format ”) shared his own experience of using this module (this time on Node.js, and not in the browser).
')
≈1⅓ years have passed ...

September 12 of the current (2013) year in the blog “ Dissatisfied with the speed of javascripts? - Wait a year and a half, and it will pass! “I expressed displeasure at the speed of the module, which I had previously written, and pointed out only one reason for optimism: the ongoing development of Node.js from version 0.6 to version 0.10 led to an increase in the speed of my code three times.

And today, the events made a full circle - I completely abandoned the use of jParser. And the achieved result (both the unpleasant and joyful side of it) turned out to be worthy of attention.

Let me share with you both the impressions and the sources.

---

The unpleasant side is this: abandoning jParser in favor of working directly with Node.js buffers inevitably leads to swelling of the code.

You can look at the changes I made on Github and judge about it yourself. Everywhere in the code, where jParser lacked one property in the object (for example, " 'MSGIDcrc': ulong "), working there with the buffer takes two lines:

nextHeader.MSGIDcrc = _JAM.JHR.readUInt32LE(offsetJHR); offsetJHR += 4; //ulong 

And here we have to deal with this writing for everyone, for each of the fields of an object read from binary data!

(My code is engaged in reading the Fidonet mail headers stored in the JAM format. Anyone who has ever read documentation on this format already knows that there are two dozen fields in this header.)

---

The good news is that the rejection of jParser significantly speeds up the work of the script. Comparing with the help of the Travis CI service, the test run time before the edits made by me, and after the edits , it is easy to see the following results:

• on Node.js version 0.6, the test went for 6526 milliseconds , and after changing the code it takes 296 milliseconds ;
  
• on Node.js version 0.8, the test went for 3682 milliseconds , and after changing the code it takes 349 milliseconds ;
  
• on Node.js version 0.10, the test went for 2147 milliseconds , and after changing the code it takes 233 milliseconds .

Acceleration is about an order of magnitude!

Having achieved such a result, it is appropriate to look at the “ Is It Worth the Time? ” Sign at the same time . "In the XKCD comic number 1205. It tells, for example, that if you spent two hours of effort (changing some code) and won one second in the operation time of such a function, which will be performed less than five times a day, then this time is wasted (because it will pay off more than five years - and after five years, what good, and the relevance of the code will be questionable).

If the speed of typing is more important for you, then use jParser: this will save effort.

If the speed of the code is more important for you, then refuse from jParser: this will speed up the script.

For my module, the acceleration per second when reading the headings of even one echo conference is quite significant, because on a typical Fidonet node there are several dozen such echo conferences, and even a few hundred on any large ( example ).

Goodbye jParser.