Оптимизация в JavaScript

Докладчик: Зуев Дмитрий

[demimurych]

Докладчик очень сильно запутался и запутал остальных.
То есть все его тесты и выводы не имеют ничего общего с реальностью. И вот почему.

JSperf это сервис, предоставляющий онлайн обертку вокруг библиотеки benchmarkjs.
benchmarkjs это библиотека которая дает апи, упрощающий организацию таких тестов. Сам по себе benchmarkjs ничего естественно не тестирует. То есть те же тесты, с тем же уровнем успеха можно было проводить в обычной консоли.

Основным недостатком и сервиса и библиотеки, является отсутствие в них хоть какой либо системы оповещения о том, что автор теста - альтернативно одарен, и ему прежде всего нужно подтянуть теорию: о том что такое Jit, как работает современный Jit, как мониторить его работу и только уж потом писать хипстерские тесты на ночь глядя. И тем более, боже упаси с их результатами получать трибуну.

То есть чтобы не случалось так как случилось у докладчика. Когда на словах проверяли одно, код написали про другое, выводы сделали третьи.

10:10 *Какой вариант эффективнее*
Не имеет ровно никакого значения который из двух вариантов эффективнее. Потому что оба варианта не имеют никакого отношения к производительному коду на Js, и все что они уверенно показывают, так это отсутствие фундаментальных знаний их автора.

*Вариант 1*
Этот код говорит о том, что автор понятия не имеет как современный v8 работает с массивами: что происходит с массивом который постоянно меняет свои размеры, как оптимизируется работа с массивами в принципе.
А между тем в современном jit есть минимум 5 вариантов разного поведения кардинально отличающихся между собой производительностью. Не считая, конечно, поведения когда ничего не оптимизируется вообще.
Иными словами, автора этого кода, нельзя подпускать к сколько нибудь зависящим от производительности задачам.

*Вариант 2*
Автор этого кода, понятия не имеет как работает современный v8 со строками. Как происходит конкатенации таких данных. От чего она зависит.

*В результате, наш докладчик в этом тесте сравнивал не декларируемую им конкатенацию, но сравнивал скорость расширения структуры данных типа массив со скоростью расширения структуры данных под строку* в условиях когда последняя расширяется на минимальные значения.

И получив очевидный результат что массив выделять дольше, чем строку, приписывает эти цифры конкатенации. Занавес.

Если бы наш докладчик, хоть немного разбирался в языке, он бы попробовал сначала объявить структуру размером эквивалентную обрабатываемым данным, после чего вынес бы ее за пределы теста. То есть получили бы код сродни этому:

_Фаза инициализации, не принимающая участие в тесте:_
var arr2=new Array(1000);

_Фаза теста:_
for (var i=0;i<1000;i++) {
arr2[i]=i;
}

var result = arr2.join(', ');

и сравнил бы результаты.

Наверное удивлению его не было бы предела когда бы он обнаружил - что *Array.prototype.join оказывает ровно в два раза быстрее String += String*

Значит ли это что мы определили победителя? Нет не значит. Почему?

Потому что всем читать документацию каждый день по три часа.
Освоить инструменты профилирования кода, познакомиться с тем что означают страшные слова вроде *trace_opt trace_deopt allow-natives-syntax*

Естественно все прочие тесты докладчика, имеют ценность ровно такую же, как и тот мусор что разобран выше.
чтобы сложить хотя бы отдаленное представление о том, как и что работает.