Как V8 измеряет производительность в реальных условиях
За последний год команда V8 разработала новую методологию для измерения и понимания производительности JavaScript в реальных условиях. Мы использовали полученные знания, чтобы изменить подход к ускорению JavaScript. Наш новый акцент на реальных условиях представляет собой значительный сдвиг в сравнении с традиционным фокусом на производительности. Мы уверены, что применение этой методологии в 2017 году существенно улучшит возможности пользователей и разработчиков полагаться на предсказуемую производительность V8 для реального JavaScript как в Chrome, так и в Node.js.
Старая поговорка "то, что измеряется, улучшается" особенно верна в мире разработки виртуальных машин (VM) для JavaScript. Выбор правильных метрик для направления оптимизации производительности является одной из самых важных задач, которую команда VM может выполнять на протяжении времени. Следующий хронологический график приблизительно иллюстрирует, как тестирование JavaScript эволюционировало с момента первого выпуска V8:
Исторически V8 и другие движки JavaScript измеряли производительность с помощью синтетических тестов. Первоначально разработчики VM использовали микротесты, такие как SunSpider и Kraken. С развитием рынка браузеров началась вторая эра тестирования, в которой использовались более крупные, но все же синтетические наборы тестов, такие как Octane и JetStream.
Микротесты и статические наборы тестов имеют несколько преимуществ: их легко создать, они просты для понимания и могут выполняться в любом браузере, что делает сравнительный анализ простым. Однако эта удобство имеет ряд недостатков. Поскольку они включают ограниченное количество тестовых случаев, сложно создать тесты, которые точно отражают характеристики интернета в целом. Более того, тесты обычно обновляются редко; следовательно, они с трудом успевают за новыми трендами и шаблонами разработки JavaScript. Наконец, за годы работы авторы VM исследовали каждый уголок традиционных тестов, в процессе чего они нашли и использовали возможности улучшения результатов тестов путем перестановки или даже пропуска невидимой работы во время выполнения тестов. Такой тип улучшения, ориентированный на результаты тестов, и чрезмерная оптимизация тестов не всегда приносит пользу пользователям или разработчикам, и история показала, что в долгосрочной перспективе очень сложно создать "недоступный для манипуляций" синтетический тест.
Измерение реальных веб-сайтов: WebPageReplay и Runtime Call Stats
Осознавая, что традиционные статические тесты показывают только часть картины производительности, команда V8 решила измерять производительность в реальных условиях, тестируя загрузку настоящих веб-сайтов. Мы хотели измерять сценарии использования, отражающие то, как конечные пользователи действительно просматривают интернет, поэтому мы решили извлекать метрики производительности с сайтов, таких как Twitter, Facebook и Google Maps. Используя инструмент Chrome под названием WebPageReplay, мы смогли записывать и воспроизводить загрузки страниц детерминированным образом.
Одновременно с этим мы разработали инструмент под названием Runtime Call Stats, который позволил нам профилировать, как разные JavaScript-коды нагружают различные компоненты V8. Впервые мы смогли не только легко тестировать изменения в V8 на реальных сайтах, но и полностью понимать, как и почему производительность V8 изменяется при разных нагрузках.
На данный момент мы мониторим изменения с набором тестов, включающим около 25 веб-сайтов, чтобы направлять оптимизацию V8. Помимо упомянутых выше сайтов и других из топ-100 Alexa, мы выбрали сайты, использующие популярные фреймворки (React, Polymer, Angular, Ember и другие), сайты из разных географических регионов, а также сайты или библиотеки, разработчики которых сотрудничали с нами, такие как Wikipedia, Reddit, Twitter и Webpack. Мы считаем, что эти 25 сайтов представляют собой широкий спектр интернета и что улучшения производительности на этих сайтах будут прямо отражаться на аналогичном ускорении других сайтов, создаваемых сегодня разработчиками JavaScript.
Для более глубокого погружения в разработку нашего набора веб-сайтов и Runtime Call Stats смотрите презентацию BlinkOn 6 о производительности в реальных условиях. Вы даже можете запустить инструмент Runtime Call Stats самостоятельно.
Создание реальной разницы
Анализ этих новых метрик производительности в реальных условиях и их сравнение с традиционными эталонными показателями с помощью Runtime Call Stats также позволили нам глубже понять, как различные рабочие нагрузки воздействуют на V8 по-разному.
На основании этих измерений мы обнаружили, что производительность Octane фактически является плохим прокси для производительности большинства из 25 протестированных нами веб-сайтов. Вы можете увидеть на графике ниже: распределение цветных столбцов Octane сильно отличается от любой другой рабочей нагрузки, особенно от нагрузки реальных веб-сайтов. При выполнении Octane узким местом V8 часто является выполнение JavaScript-кода. Однако большинство реальных веб-сайтов вместо этого нагружают парсер и компилятор V8. Мы поняли, что оптимизации, сделанные для Octane, часто практически не воздействовали на реальные веб-страницы, а в некоторых случаях эти оптимизации делали реальные веб-сайты медленнее.
Мы также выяснили, что другой тестовый показатель оказался более близким к реальным веб-сайтам. Speedometer, эталонный тест от WebKit, включающий приложения, написанные на React, Angular, Ember и других фреймворках, показал профиль времени выполнения, очень похожий на 25 сайтов. Хотя ни один эталонный тест не соответствует точности реальных веб-страниц, мы считаем, что Speedometer лучше моделирует рабочие нагрузки современного JavaScript в интернете, чем Octane.
Итог: более быстрый V8 для всех
За последний год тестовый набор реальных веб-сайтов и наш инструмент Runtime Call Stats позволили нам внедрить оптимизации производительности V8, которые ускоряют загрузку страниц в среднем на 10-20%. Учитывая историческую направленность на оптимизацию загрузки страниц в Chrome, двузначное улучшение этого показателя в 2016 году является значительным достижением. Те же самые оптимизации также улучшили наш результат на Speedometer на 20-30%.
Эти улучшения производительности должны быть отражены на других сайтах, созданных веб-разработчиками с использованием современных фреймворков и похожих шаблонов JavaScript. Наши улучшения встроенных функций, таких как Object.create и Function.prototype.bind, оптимизации шаблона фабрики объектов, работа над inline caches в V8 и продолжающиеся улучшения парсера предназначены для широкого применения в недооцененных областях JavaScript, которыми пользуются все разработчики, а не только те, кто разрабатывает сайты, представленные в нашем наборе.
Мы планируем расширить использование реальных веб-сайтов для направления работы по улучшению производительности V8. Следите за новостями, чтобы узнать больше о тестах и производительности скриптов.