Перелистнём несколько страниц недавнего прошлого.

16 мая 2012 года RReverser во блогозаписи «Javascript BMP Parser» рассказал об употреблении модуля jParser для ан��лиза двоичных данных, во браузере совершаемого.

На следующий же день (17 мая 2012 года) во блогозаписи «jParser: анализ двоичных файлов работает просто» я перевёл документацию по jParser, а чуть позже (22 мая 2012 года во блогозаписи «Node.js на узле Фидонета: читаем джаваскриптом заголовки эхопочты, хранимой в формате JAM») поделился собственным опытом употребления этого модуля (на сей раз — на Node.js, а не во браузере).

Прошло ≈1⅓ года…

12 сентября нынешнего (2013) года во блогозаписи «Недоволен скоростью джаваскриптов? — Подожди год-полтора, и это пройдёт!» я выразил неудовольствие от скорости работы модуля, прежде мною сочинённого, и указал на один только повод для оптимизма: поступательное развитие Node.js от версии 0.6 до версии 0.10 привело к росту скорости моего кода в три раза.

А сегодня события совершили полный круг — я напрочь отказался от употребления jParser. И достигнутый результат (как неприятная, так и радостная сторона его) оказался заслуживающим внимания.

Позвольте же поделиться с вами как впечатлениями, так и исходниками.


Неприятная сторона вот какова: отказ от jParser в пользу работы напрямую с буферами Node.js неизбежно приводит к распуханию кода.

Вы можете посмотреть на Гитхабе внесённые мною правки и судить о том самостоятельно. Всюду в коде, где для jParser хватало одного свойства в объекте (например, «'MSGIDcrc': ulong»), там работа с буфером занимает две строки:

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

И вот такою писаниною приходится заниматься для каждого, для каждого из полей объекта, считываемого из двоичных данных!

(Мой код занимается чтением заголовков фидонетовской почты, хранимой в формате JAM. Всякий, кто когда-либо читал документацию по этому формату, уж знает, что в таком заголовке — два десятка полей.)


Радостная же новость заключается в том, что отказ от jParser существенно ускоряет работу скрипта. Сравнив при помощи сервиса Travis CI время работы теста до правок, мною внесённых, и после правок, нетрудно увидать следующие результаты:


Ускорение примерно на порядок!

Достигнув такого результата, уместно заодно посмотреть и на табличку «Is It Worth the Time?» в комиксе XKCD №1205. Там рассказывается, например, что если Вы потратили два часа усилий (переменив некоторый код) и выиграли одну секунду во времени работы такой функции, которая станет выполняться реже пяти раз в сутки, то это время потрачено зря (потому что окупаться оно будет больше пяти лет — а после пяти лет, чего доброго, и актуальность кода окажется под вопросом).

Если скорость набора кода важнее для вас, то используйте jParser: это позволит экономить усилия.

Если скорость работы кода важнее для вас, то откажитеся от jParser: это позволит ускорить��скрипт.

Для моего-то модуля ускорение на секунду при чтении заголовков даже одной эхоконференции весьма существенно, потому что на типичном узле Фидонета таких эхоконференций бывает несколько десятков, а на сколько-нибудь крупном — даже несколько сотен (пример).

Прощай, jParser.