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