Вы вообще статью читали? Тест прогоняется N раз, потом результат делится на N.
Значение N подбирается исходя из оценки времени работы теста и нужной точности.
Имелось ввиду измерение кванта времени. Это чисто теоретический интерес.
Похожая мысль была выражена в комментарии(второй пункт).
А комментарий сдвинулся, слишком долго :) писал ответ.
Всё же, повторять без перекомпиляции не слишком надёжно — браузер может между повторами соптимизировать функцию. Если же мы генерируем огромную функцию и запускаем её лишь раз, то можно быть уверенными, что никакие jit оптимизации применены не будут.
Тезис про return — мимо кассы, return всё же должен быть внутри function, а код теста должен быть валидным JS и не полагаться, что его кто-то обернёт в функцию. Кроме того, этот тезис относится ко всем шаблонам.
Потребление памяти — не столь важно для бенчмарков. GC на объёмы памяти тоже положить — ему важно число объектов. Время компиляции тоже. Хотя в старой опере компиляция гигантских функций могла длиться катастрофически долго.
Но ведь главный use case JSPerf — сравнивать два или несколько сниппетов. Абсолютная скорость не имеет значения, важно только понять, какой из сниппетов быстрее относительно других и на сколько процентов.
Хотелось бы попрдробнее узнать о методике Benchmark.js: как именно выбирается количество повторов, что значит «столько раз, чтобы получить статистически значимые результаты»? Есть ли такая информация?
Пуленепробиваемые тесты JavaScript