-uskoryaet skript-na poryadok.png "Отказ от jParser (в пользу работы напрямую с буферами Node.js) ускоряет скрипт на порядок")
Перелистнём несколько страниц недавнего прошлого.
16 мая 2012 года RReverser во блогозаписи «Javascript BMP Parser» рассказал об употреблении модуля jParser для анализа двоичных данных, на движке Node.js совершаемого.
На следующий же день (17 мая 2012 года) во блогозаписи «jParser: анализ двоичных файлов работает просто» я перевёл документацию по jParser, а чуть позже (22 мая 2012 года во блогозаписи «Node.js на узле Фидонета: читаем джаваскриптом заголовки эхопочты, хранимой в формате JAM») поделился собственным опытом употребления этого модуля.
Прошло ≈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 время работы теста до правок, мною внесённых, и после правок, нетрудно увидать следующие результаты:
- на Node.js версии 0.6 тест шёл 6526 миллисекунд, а после изменений кода проходит за 296 миллисекунд;
- на Node.js версии 0.8 тест шёл 3682 миллисекунды, а после изменений кода проходит за 349 миллисекунд;
- на Node.js версии 0.10 тест шёл 2147 миллисекунд, а после изменений кода проходит за 233 миллисекунды.
Ускорение примерно на порядок!
Достигнув такого результата, уместно заодно посмотреть и на табличку «Is It Worth the Time?» в комиксе XKCD №1205. Там рассказывается, например, что если Вы потратили два часа усилий (переменив некоторый код) и выиграли одну секунду во времени работы такой функции, которая станет выполняться реже пяти раз в сутки, то это время потрачено зря (потому что окупаться оно будет больше пяти лет — а после пяти лет, чего доброго, и актуальность кода окажется под вопросом).
Если скорость набора кода важнее для вас, то используйте jParser: это позволит экономить усилия.
Если скорость работы кода важнее для вас, то откажитеся от jParser: это позволит ускорить скрипт.
Для моего-то модуля ускорение на секунду при чтении заголовков даже одной эхоконференции весьма существенно, потому что на типичном узле Фидонета таких эхоконференций бывает несколько десятков, а на сколько-нибудь крупном — даже несколько сотен (пример).
Прощай, jParser.
Автор: Mithgol
