Discussion :

[Bill Fassinou]

V8, le moteur JavaScript de Google, est désormais plus léger
avec 22 % de charge de mémoire en moins

V8 est le moteur JavaScript et WebAssembly hautes performances et open source de Google écrit en C++. Il est utilisé dans Chrome et dans Node.js, entre autres. Il implémente ECMAScript et WebAssembly, et s'exécute sur les systèmes Windows 7 ou les versions ultérieures, macOS 10.12+ et Linux utilisant des processeurs x64, IA-32, ARM ou MIPS. V8 peut fonctionner de manière autonome ou peut être intégré à n’importe quelle application C++. Depuis fin 2018, le moteur a subi quelques améliorations et est désormais plus léger, avec 20 % de charge de mémoire en moins.

V8 est le moteur JavaScript libre et open source utilisé par Google dans les navigateurs Chromium et Google Chrome, il est également utilisé par la plateforme Node.js. Ce mercredi, l’équipe de développement du moteur V8 a annoncé qu’elle a apporté un certain nombre d’optimisations clés au moteur qui le rendent désormais plus léger et qui lui permettent d’utiliser moins de mémoire. Ces optimisations étaient initialement prévues dans un projet connexe dénommé V8 Lite, mais ont finalement été incorporées à la version standard du V8.

Selon l’équipe de développement du moteur, le projet V8 Lite visait à réduire considérablement l'utilisation de la mémoire du V8. Initialement, ce projet était envisagé comme un mode distinct du V8, spécialement conçu pour les périphériques mobiles utilisant peu de mémoire ou les cas d'utilisation qui se soucient davantage de la réduction de l'utilisation de la mémoire que de la vitesse d'exécution. Cependant, l’équipe s’est rendu compte que ces optimisations pouvaient être intégrées à la version standard du moteur et elle a donc procédé ainsi.

Grâce à ces améliorations, le moteur V8 de Google utilise désormais 22 % moins de mémoire que les versions précédentes. En analysant la manière dont la mémoire est utilisée par le moteur V8, l’équipe s’est rendu compte qu’une grande partie du segment de mémoire était dédiée à des objets qui ne sont pas essentiels à l'exécution de JavaScript, mais qui sont utilisés pour optimiser l'exécution de JavaScript et gérer des situations exceptionnelles. Ainsi, elle a décidé de réduire considérablement la mémoire allouée à l’optimisation.

Le mode Lite a été lancé dans la version 7.3 de V8. Selon l’équipe, la désactivation de l'optimisation du code offre une réduction de 22 % de la taille des pages Web par rapport à la version V8 v7.1. Il n’alloue plus les vecteurs de retour et n’actualise pas le code rarement exécuté. « C'est un bon résultat pour les applications qui veulent explicitement sacrifier les performances pour une meilleure utilisation de la mémoire », a déclaré l’équipe.

La deuxième amélioration apportée par le projet V8 Lite est le « Feedback Vector ». En effet, bien que cette modification ait permis de rendre le moteur moins gourmand en mémoire, elle empiète sur les performances du V8. La désactivation de l’allocation de vecteur de retour empêche l’optimisation du code par le compilateur TurboFan du V8. Il empêche également la mise en cache en ligne (inline caching) des opérations courantes comme le chargement de propriétés d’objet dans l’interpréteur Ignition.

Cela entraîne une régression significative du temps d'exécution de V8, réduisant le temps de chargement des pages de 12 % et augmentant le temps CPU du V8 de 120 % dans des scénarios de pages Web interactives typiques. Pour rappel, le temps CPU (CPU Time) est le temps passé par un programme sur le processeur. Ce temps est une constante et il ne dépend pas de la charge de travail de votre machine. Pour éviter ces régressions, l’équipe a opté pour une allocation paresseuse des vecteurs de retour après que la fonction ait exécuté une certaine quantité de bytecode.

Cette quantité de bytecode est actuellement de 1 Ko. Ce mode de fonctionnement apporté par V8 Lite permet d’empêcher les régressions de performances tout en permettant l’optimisation du code.

Par ailleurs, une autre optimisation apportée par le projet V8 Lite est appelée « Lazy source positions ». Selon l’équipe, lors de la compilation du bytecode à partir de JavaScript, des tables de position source sont générées et lient les séquences de bytecode aux positions des caractères dans le code source JavaScript.

Cependant, cette information n'est nécessaire que pour symboliser des exceptions ou exécuter des tâches de développement telles que le débogage, elle est donc rarement utilisée. Pour éviter ce gaspillage, V8 compile maintenant le bytecode sans collecter les positions des sources (en supposant qu'aucun débogueur ou profileur ne soit attaché). Les positions sources ne sont collectées que lorsqu'une trace de pile est effectivement générée. Par exemple lors de l'appel de Error.stack ou de l'impression de la trace d'une exception de pile vers la console.

Toutefois, cela a un certain coût. D’autres optimisations sont à noter dans le projet V8 Lite, notamment le « bytecode flushing », la réduction de la taille des objets FunctionTemplateInfo (ce sont des objets qui stockent des métadonnées internes sur les FunctionTemplates), etc. Vous pouvez retrouver toutes les optimisations sur le blog du moteur V8. En gros, la taille du moteur V8 a été réduite de 18 % en moyenne sur une gamme de sites Web typiques, ce qui correspond à une diminution moyenne de 1,5 Mo pour les appareils mobiles Android Go de bas de gamme (1 Go de RAM ou moins).

Cela a été possible sans impact significatif sur les performances JavaScript, que ce soit sur les benchmarks ou sur les interactions des pages Web typiques. Le mode Lite peut fournir d'autres économies de mémoire avec parfois un impact sur le temps d'exécution JavaScript en désactivant l'optimisation des fonctions. En moyenne, le mode Lite permet d'économiser 22 % de mémoire, certaines pages affichant jusqu'à 32 % de réduction. Cela correspond à une réduction de 1,8 Mo de la taille du tas V8 sur un appareil Android Go.

Source : V8

Et vous ?

Qu'en pensez-vous ?

Voir aussi

Le moteur de JavaScript V8 de Chrome bénéficie d'un lot d'améliorations, afin de le rendre plus rapide et moins lourd

LEONARDI Application Suite V8.6 et V8.7 : le player W4 Android permet aux terminaux mobiles d'interagir avec les applications métiers

Le WebAssembly serait moins performant en terme de rapidité que le code natif, selon les résultats d'une étude

[yahiko]

Excellente nouvelle dans la mesure où l'empreinte en mémoire était le principal défaut, sinon le seul, qui pouvait être reproché à Google Chrome.
Après tant d'années d'existence, il est assez remarquable que ce navigateur ait encore pu trouver des marges de progression significatives (-22% de consommation mémoire, c'est même beaucoup).

Tous ces progrès sur les moteurs JavaScript, que ce soit celui de Chrome ou de Firefox, montrent que les applications JavaScript sous navigateur deviennent davantage chaque jour de réelles alternatives à des développements sur clients lourds (je pense notamment à Java côté Android ou à du C/C++/autre côté Desktop).

[LeBressaud]

Excellente nouvelle dans la mesure où l'empreinte en mémoire était le principal défaut, sinon le seul, qui pouvait être reproché à Google Chrome.
Après tant d'années d'existence, il est assez remarquable que ce navigateur ait encore pu trouver des marges de progression significatives (-22% de consommation mémoire, c'est même beaucoup).

Dans ce cas la réduction de l'empreinte mémoire se fait au détriment des performances, d'ailleurs le temps CPU augmente de 120%.

Les PC actuels ont beaucoup de mémoire, pourquoi s'en priver et ne pas optimiser le bytecode si elle n'est pas utilisée ?

[micka132]

Tous ces progrès sur les moteurs JavaScript, que ce soit celui de Chrome ou de Firefox, montrent que les applications JavaScript sous navigateur deviennent davantage chaque jour de réelles alternatives à des développements sur clients lourds (je pense notamment à Java côté Android ou à du C/C++/autre côté Desktop).

Autant pour des applications gestions classiques il n'y a pas forcément besoin d'envoyer du lourd, donc on peut remplacer java, autant pour les applications ayant besoin de performance, il y a un univers parallèle entre JS et C/C++!