12 articles tagués avec « benchmarks »

Chez V8, nous nous efforçons constamment d'améliorer les performances de JavaScript. Dans le cadre de cet effort, nous avons récemment revisité la suite de tests JetStream2 pour éliminer les goulets d'étranglement de performance. Cet article détaille une optimisation spécifique que nous avons réalisée et qui a permis une amélioration significative de 2.5x dans le test async-fs, contribuant ainsi à une augmentation notable du score global. L'optimisation a été inspirée par le test, mais de tels motifs apparaissent également dans le code du monde réel.

Bienvenue dans le monde passionnant de V8, où la vitesse n'est pas seulement une caractéristique mais un mode de vie. Alors que nous disons adieu à 2023, il est temps de célébrer les réalisations impressionnantes que V8 a accomplies cette année.

Grâce à des optimisations innovantes en termes de performances, V8 continue de repousser les limites de ce qui est possible dans le paysage toujours en évolution du Web. Nous avons introduit un nouveau compilateur de niveau intermédiaire et mis en œuvre plusieurs améliorations dans l'infrastructure du compilateur de haut niveau, le runtime et le ramasse-miettes, ce qui a entraîné des gains de vitesse significatifs dans tous les domaines.

Pendant son stage de trois mois au sein de l'équipe V8, Hai Dang a travaillé à améliorer les performances de [...array], [...string], [...set], [...map.keys()], et [...map.values()] (quand les éléments de propagation sont au début du littéral de tableau). Il a même rendu Array.from(iterable) beaucoup plus rapide. Cet article explique certains détails techniques de ses modifications, incluses dans V8 à partir de la version 7.2.

Le traitement asynchrone en JavaScript avait traditionnellement la réputation de ne pas être particulièrement rapide. Pour aggraver les choses, le débogage d'applications JavaScript en direct — en particulier des serveurs Node.js — n'est pas chose aisée, surtout lorsqu'il s'agit de programmation asynchrone. Heureusement, les temps changent. Cet article explore comment nous avons optimisé les fonctions asynchrones et les promesses dans V8 (et dans une certaine mesure dans d'autres moteurs JavaScript également), et décrit comment nous avons amélioré l'expérience de débogage de code asynchrone.

DataView est l'une des deux manières possibles de réaliser des accès mémoire à bas niveau en JavaScript, l'autre étant TypedArray. Jusqu'à présent, les DataView étaient beaucoup moins optimisés que les TypedArray dans V8, ce qui entraînait de moins bonnes performances dans des tâches comme les charges de travail intensives en graphismes ou lors du décodage/encodage de données binaires. Les raisons de cela étaient principalement des choix historiques, comme le fait que asm.js avait opté pour les TypedArray au lieu des DataView, incitant ainsi les moteurs à se concentrer sur les performances des TypedArray.

Ce mois-ci marque le 10e anniversaire de la sortie non seulement de Google Chrome, mais aussi du projet V8. Ce post offre un aperçu des grandes étapes du projet V8 au cours des 10 dernières années ainsi que les années précédentes, lorsque le projet était encore secret.

Depuis la sortie initiale de Speedometer 1.0 en 2014, les équipes Blink et V8 utilisent ce benchmark comme proxy pour l'utilisation réelle des frameworks JavaScript populaires et ont réalisé des gains de vitesse considérables sur ce benchmark. Nous avons vérifié indépendamment que ces améliorations se traduisent par des bénéfices réels pour les utilisateurs en mesurant sur des sites Web réels et avons observé que les améliorations des temps de chargement des pages des sites populaires ont également amélioré le score de Speedometer.

La performance du JavaScript a toujours été importante pour l'équipe V8, et dans cet article, nous souhaitons discuter d'un nouveau Web Tooling Benchmark que nous avons récemment utilisé pour identifier et corriger certains goulots d'étranglement en termes de performance dans V8. Vous connaissez peut-être déjà l'engagement fort de V8 envers Node.js, et ce benchmark prolonge cet engagement en exécutant spécifiquement des tests de performance basés sur des outils courants de développement construits sur Node.js. Les outils du Web Tooling Benchmark sont les mêmes que ceux utilisés aujourd'hui par les développeurs et concepteurs pour créer des sites web modernes et des applications basées sur le cloud. Dans le prolongement de nos efforts continus pour nous concentrer sur la performance réelle plutôt que sur des benchmarks artificiels, nous avons créé le benchmark en utilisant le code réel que les développeurs exécutent quotidiennement.

Les proxies sont une partie intégrante de JavaScript depuis ES2015. Ils permettent d'intercepter les opérations fondamentales sur les objets et de personnaliser leur comportement. Les proxies constituent une partie centrale de projets comme jsdom et la bibliothèque RPC Comlink. Récemment, nous avons investi beaucoup d'efforts pour améliorer les performances des proxies dans V8. Cet article met en lumière les modèles généraux d'amélioration des performances dans V8 et pour les proxies en particulier.

L'histoire des benchmarks JavaScript est une histoire d'évolution constante. Alors que le web est passé de simples documents à des applications dynamiques côté client, de nouveaux benchmarks JavaScript ont été créés pour mesurer des charges de travail devenues importantes pour de nouveaux cas d'utilisation. Ce changement constant a donné aux benchmarks individuels une durée de vie limitée. À mesure que les navigateurs web et les implémentations de machines virtuelles (VM) commencent à sur-optimiser pour des cas de test spécifiques, les benchmarks eux-mêmes cessent de devenir des proxies efficaces pour leurs cas d'utilisation d'origine. L'un des premiers benchmarks JavaScript, SunSpider, a fourni des incitations précoces à la livraison de compilateurs d'optimisation rapides. Cependant, à mesure que les ingénieurs des VM ont découvert les limitations des microbenchmarks et trouvé de nouvelles façons de optimiser autour des limites de SunSpider, la communauté des navigateurs web a retiré SunSpider en tant que benchmark recommandé.