Зрівняння продуктивності Node.js 0.11.15 та io.js 1.0.3

Попереджаю, це буде сухий і нудний пост. Серйозно. Якщо ви не хочете даремно витратити свій час, просто йдіть далі.
Щож, схоже, ви ще тут, не кажіть потім, що я вас не попереджав.
У минулому своєму пості я порівнював продуктивність Node.js 0.10.35 та io.js 1.0.2. Але так як вчора у обох синхронно вийшли нові версії, думаю можна провести повторний тест. Особливо, якщо враховувати той факт, що зробили вони це на наступний день після моєї публікації.

Що я тестував

Як і минулого разу тест буде проводитися решетом Ератосфену, реалізованому на звичайному масиві, типизованому масиві або буфері.
Сьогодні буде більше розмов про числа (я ж казав, що буде нудно). У коментарях про мою статтю на Hacker-News є цікавий аналіз того, чому деякі дані про продуктивність в моєму останньому тесті виглядають дивно. и повернемося до цього далі в цьому пості.

Як і минулого разу, я повторював кожен тест по 7 разів, а в якості результату брав медіану. Конфігурація моєї машини: 64-bit OpenSuse 13.2 на Intel i7-4771 3,5ГГц.

Результати

Оригінальний тест без будь-яких змін і аргументів у командному рядку:

                 Node.js 0.11.15        io.js 1.0.3
Buffer           4.991                  5.009
Typed-Array      11.275                 11.518
Regular Array    7.440                  7.346
(Час у секундах)

Як я і говорив, нічого цікавого, продуктивність майже однакова, до того ж, вона мало змінилася з попередніх версій.
Але, на щастя, це не все. Я згадав обговорення на Hackernews, де в одному коментарі дехто, хто підписався як mraleph висловив цікаву думку з приводу того, чому саме робота з типізованими масивами показує гірші результати в io.js.
Можлива причина того, чому я перестав використовувати будь-які різновиди uint8array, в тому, що клас uint8array вивантажується і заново створюється щоразу перед запуском тесту. Тому я змінив код так, що додав в нього фіктивний клас uint8array, який створюється перед запуском тестів і знаходиться у виділеному місці під час їх виконання. Я вже відзвітував на Hacker-News, що це вирішує проблему падіння швидкості тестів з типізованими масивами на io.js 1.0.2.
Mraleph запропонував інше рішення проблеми, яке складається з того, щоб додати аргумент командного рядка --nouse-osr. OSR - технологія, яка дозволяє оптимізувати роботу функції під час її виконання.
Починаються числа...
Існування uint8array підтримується, але без аргументу --nouse-osr:

             Node.js 0.11.15        io.js 1.0.3
Buffer           4.995                  5.024
Typed-Array      5.501                  5.510
Regular Array    7.443                  7.375

Крім того, що час для типізованих масивів зменшився вдвічі, немає ніяких істотних відмінностей від попередніх результатів, швидкість обробки регулярних масивів і буфер залишилися колишніми.

Існування uint8array не підтримується додатковим класом, але застосований аргумент --nouse-osr:

             Node.js 0.11.15        io.js 1.0.3
Buffer           4.289                  4.325
Typed-Array      4.997                  5.052
Regular Array    6.683                  6.731

Як бачите цей спосіб покращує продуктивність не тільки для типізованих масивів, але також для регулярних і буферів. Підвищення становить приблизно 15% для буферів і 10% для масивів.

Добре, тепер давайте спробуємо використовувати два методи одночасно і подивимося, що буде:

                 Node.js 0.11.15        io.js 1.0.3
Buffer           4.275                  4.342
Typed-Array      4.985                  5.042
Regular Array    6.702                  6.770

Результат не відрізняється від попереднього тесту.
Таким чином напрошується висновок, що використовуючи параметр --nouse-osr, вам не треба турбуватися про утримуванні класу uint8array живими. Ще один висновок, який можна зробити після проведення цього тексту, полягає в тому, що продуктивність node.js та io.js в нових версіях практично однакова.
Якщо ви читаєте це, то, мабуть, не прислухалися до моєї поради та дочитали до кінця. Що ж вітаю, з цього часу можете офіційно називати себе гіком.