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

16 мая 2012 года RReverser ^[1] во блогозаписи «Javascript BMP Parser ^[2]» рассказал об употреблении модуля jParser ^[3] для анализа двоичных данных, на движке Node.js совершаемого.

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

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

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

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

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

---

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

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

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

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

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

---

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

• на Node.js версии 0.6 тест шёл 6526 миллисекунд ^[12], а после изменений кода проходит за 296 миллисекунд ^[13];
   
• на Node.js версии 0.8 тест шёл 3682 миллисекунды ^[14], а после изменений кода проходит за 349 миллисекунд ^[15];
   
• на Node.js версии 0.10 тест шёл 2147 миллисекунд ^[16], а после изменений кода проходит за 233 миллисекунды ^[17].

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

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

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

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

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

Прощай, jParser.

Автор: Mithgol

Источник ^[20]