Comment V8 mesure les performances réelles

Au cours de l'année passée, l'équipe V8 a mis au point une nouvelle méthodologie pour mesurer et comprendre les performances réelles de JavaScript. Nous avons utilisé les enseignements que nous en avons tirés pour changer la façon dont l'équipe V8 accélère JavaScript. Notre nouvel objectif axé sur le monde réel représente un changement significatif par rapport à notre approche traditionnelle des performances. Nous sommes convaincus qu'en continuant d'appliquer cette méthodologie en 2017, cela améliorera significativement la capacité des utilisateurs et des développeurs à s'appuyer sur des performances prévisibles de V8 pour les JavaScript réels dans Chrome et Node.js.

Le vieil adage « ce qui est mesuré s'améliore » est particulièrement vrai dans le monde du développement des machines virtuelles (VM) JavaScript. Choisir les bons indicateurs pour guider l'optimisation des performances est l'une des choses les plus importantes qu'une équipe de VM puisse faire au fil du temps. La chronologie suivante illustre de manière approximative comment les benchmarks JavaScript ont évolué depuis la sortie initiale de V8 :

Historiquement, V8 et d'autres moteurs JavaScript ont mesuré les performances à l'aide de benchmarks synthétiques. Initialement, les développeurs de VM utilisaient des microbenchmarks comme SunSpider et Kraken. À mesure que le marché des navigateurs mûrissait, une deuxième ère de benchmarking commença, au cours de laquelle ils utilisaient des suites de tests plus larges mais néanmoins synthétiques comme Octane et JetStream.

Les microbenchmarks et les suites de tests statiques présentent quelques avantages : ils sont faciles à démarrer, simples à comprendre, et peuvent être exécutés dans n'importe quel navigateur, facilitant ainsi l'analyse comparative. Mais cette commodité a un certain nombre d'inconvénients. Parce qu'ils incluent un nombre limité de cas de test, il est difficile de concevoir des benchmarks qui reflètent avec précision les caractéristiques du web dans son ensemble. De plus, les benchmarks sont généralement mis à jour peu fréquemment ; ainsi, ils ont tendance à avoir du mal à suivre les nouvelles tendances et les modèles de développement JavaScript récents. Enfin, au fil des années, les auteurs de VM ont exploré chaque recoin des benchmarks traditionnels, et dans le processus, ils ont découvert et exploité des opportunités pour améliorer les scores des benchmarks en réorganisant ou même en sautant des travaux non observables de l'extérieur pendant l'exécution des benchmarks. Ce type d'amélioration guidée par le score des benchmarks et d'optimisation excessive pour les benchmarks n'apporte pas toujours beaucoup d'avantages pour les utilisateurs ou les développeurs, et l'histoire a montré qu'à long terme, il est très difficile de créer un benchmark synthétique « infalsifiable ».

Mesurer les sites Web réels : WebPageReplay & Runtime Call Stats

Avec la conviction que nous ne voyions qu'une partie des performances grâce aux benchmarks statiques traditionnels, l'équipe V8 a entrepris de mesurer les performances réelles en évaluant le chargement de véritables sites web. Nous voulions mesurer des cas d'utilisation reflétant comment les utilisateurs naviguaient réellement sur le web, nous avons donc décidé de dériver des indicateurs de performance de sites web comme Twitter, Facebook et Google Maps. En utilisant une infrastructure Chrome appelée WebPageReplay, nous avons pu enregistrer et rejouer les chargements de pages de manière déterministe.

Parallèlement, nous avons développé un outil appelé Runtime Call Stats qui nous a permis de profiler comment différents codes JavaScript sollicitaient différents composants de V8. Pour la première fois, nous avions la possibilité non seulement de tester facilement les changements apportés à V8 sur de vrais sites web, mais aussi de comprendre pleinement comment et pourquoi V8 fonctionnait différemment sous différentes charges de travail.

Nous surveillons désormais les changements par rapport à une suite de tests comprenant environ 25 sites web afin de guider l'optimisation de V8. En plus des sites mentionnés précédemment et d'autres issus du Top 100 d'Alexa, nous avons sélectionné des sites mis en œuvre à l'aide de frameworks courants (React, Polymer, Angular, Ember, et plus), des sites provenant de différentes régions géographiques, ainsi que des sites ou des bibliothèques dont les équipes de développement ont collaboré avec nous, comme Wikipédia, Reddit, Twitter et Webpack. Nous pensons que ces 25 sites sont représentatifs du web dans son ensemble et que les améliorations de performance sur ces sites se traduiront directement par des accélérations similaires pour les sites développés aujourd'hui par les développeurs JavaScript.

Pour une présentation détaillée sur le développement de notre suite de tests de sites web et Runtime Call Stats, consultez la présentation BlinkOn 6 sur les performances réelles. Vous pouvez même exécuter vous-même l'outil Runtime Call Stats.

Faire une réelle différence

Analyser ces nouvelles métriques de performance en conditions réelles et les comparer aux benchmarks traditionnels avec Runtime Call Stats nous a également donné plus d'informations sur la manière dont diverses charges de travail sollicitent V8 de différentes manières.

À partir de ces mesures, nous avons découvert que les performances d'Octane étaient en réalité un mauvais indicateur des performances pour la majorité des 25 sites web testés. Vous pouvez voir dans le graphique ci-dessous : la distribution des barres de couleurs d'Octane est très différente de celle de toute autre charge de travail, en particulier celles des sites web en conditions réelles. Lors de l'exécution d'Octane, le goulot d'étranglement de V8 est souvent l'exécution du code JavaScript. Cependant, la plupart des sites web réels sollicitent plutôt le parseur et le compilateur de V8. Nous nous sommes rendu compte que les optimisations faites pour Octane avaient souvent peu d'impact sur les pages web en conditions réelles, et dans certains cas ces optimisations rendaient les sites web réels plus lents.

Nous avons également découvert qu'un autre benchmark était en réalité un meilleur indicateur pour les sites web réels. Speedometer, un benchmark WebKit qui inclut des applications développées avec React, Angular, Ember et d'autres frameworks, a présenté un profil d'exécution très similaire aux 25 sites. Bien qu'aucun benchmark ne corresponde parfaitement à la fidélité des pages web réelles, nous pensons que Speedometer simule mieux les charges de travail réelles du JavaScript moderne sur le web qu'Octane.

Conclusion : un V8 plus rapide pour tous

Au cours de l'année dernière, la suite de tests des sites web réels et notre outil Runtime Call Stats nous ont permis d'apporter des optimisations de performance à V8 qui accélèrent le chargement des pages de manière générale de 10 à 20 % en moyenne. Étant donné la concentration historique sur l'optimisation du chargement des pages dans Chrome, une amélioration à deux chiffres de cette métrique en 2016 est une réalisation significative. Les mêmes optimisations ont également amélioré notre score sur Speedometer de 20 à 30 %.

Ces améliorations de performance devraient se refléter dans d'autres sites développés par des développeurs web utilisant des frameworks modernes et des modèles similaires de JavaScript. Nos améliorations sur les fonctions intégrées telles que Object.create et Function.prototype.bind, les optimisations autour du modèle de la fabrique d'objets, le travail sur les caches en ligne de V8, et les améliorations continues du parseur sont conçus pour être des améliorations globalement applicables à des zones méconnues du JavaScript utilisées par tous les développeurs, pas uniquement les sites représentatifs que nous suivons.

Nous prévoyons d'étendre notre utilisation des sites web réels pour orienter le travail de performance de V8. Restez connectés pour davantage d'informations sur les benchmarks et les performances des scripts.