Возможно, вы недавно видели некоторые заголовки о планах Google удалить свой набор тестов Octane JavaScript . Если вы не знаете об этом или не читали за заголовком, позвольте мне кратко повторить. Google представила Octane вместо стандартного эталонного теста SunSpider. SunSpider был создан командой Apple Safari и был одним из первых тестов JavaScript.
Были две проблемы с SunSpider. Прежде всего, он основывался на микробенчмарках (подумайте, тестируя создание нового массива тысячи раз), которые не очень точно отражали реальное использование. Во-вторых, ранжирование SunSpider стало иметь большой вес среди разработчиков браузеров, в результате чего некоторые оптимизировали свои движки JavaScript для лучших результатов тестов, а не для нужд реальных программ. В некоторых случаях эти изменения даже приводят к тому, что рабочий код работает медленнее, чем раньше!
Octane сконцентрировался на попытках создать тесты, которые более точно моделировали бы реальные рабочие нагрузки, и стал стандартом, по которому измерялись реализации JavaScript. Тем не менее, производители браузеров снова догнали, и мы видим оптимизации, адаптированные к тестам Октана. Это не значит, что тесты не были полезны. Конкуренция между браузерами привела к значительному улучшению производительности JavaScript по всем направлениям.
Вы можете сказать, что это довольно интересно, но как это влияет на мою повседневную работу в качестве разработчика? Тесты часто цитируются при попытке убедить людей в преимуществах фреймворка y по сравнению с фреймворком x, и некоторые люди придают большое значение этим цифрам. На прошлой неделе я заметил, что новая библиотека пользовательского интерфейса MoonJS выполняет обход некоторых новостных агрегаторов. MoonJS позиционирует себя как «минимальную, невероятно быструю» библиотеку и приводит некоторые контрольные цифры, чтобы попытаться подтвердить это.
Чтобы было ясно, я не выбираю MoonJS здесь. Такое внимание к скорости довольно распространено, особенно среди библиотек пользовательского интерфейса (в качестве примера рассмотрим любой из клонов React). Как мы видели выше на примерах SunSpider и Octane, тесты могут вводить в заблуждение. Многие современные библиотеки представлений JavaScript и фреймворки используют некоторую форму виртуального DOM для визуализации вывода. В процессе исследования различных реализаций Борис Каул потратил некоторое время на поиск способов сравнения производительности виртуальных DOM и обнаружил, что настроить производительность VDOM относительно легко, чтобы добиться хороших результатов в тестах. Его вывод? «Не используйте числа из каких-либо тестов веб-фреймворка, чтобы принять решение, когда вы выбираете фреймворк или библиотеку».
Существуют и другие причины для осторожности при сравнении библиотек на основе заявленной скорости. Важно помнить, что, как и SunSpider, многие тесты являются микробенчмарками; Они измеряют повторяющиеся операции в масштабе, который вы вряд ли будете соответствовать при создании интерфейсов для ваших приложений.
Также стоит спросить, насколько важна скорость для вашего конкретного случая использования. Создание простого CRUD-приложения вряд ли поставит какую-либо библиотеку пользовательского интерфейса на колени, и такие важные факторы, как кривая обучения, доступный кадровый потенциал и счастье разработчика, также являются важными факторами. В прошлом я видел много дискуссий о том, был ли Ruby слишком медленным для создания веб-приложений, но, несмотря на более быстрые варианты, многие приложения были и продолжают писать на Ruby.
Метрики скорости могут вводить в заблуждение, но они также могут иметь ограниченное использование в зависимости от того, что вы строите. Как и со всеми практическими правилами и хорошими практиками, всегда хорошо остановиться и подумать, как (или если) это относится к вашей ситуации. Мне интересно услышать ваш опыт: использовали ли вы программное обеспечение, которое на практике не соответствовало требованиям стандарта? Вы создавали приложения, где разница в скорости была важна? Оставьте мне комментарий и дайте мне знать!