Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Redacteur
    Inscrit en
    juin 2016
    Messages
    926
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Redacteur
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2016
    Messages : 926
    Points : 25 676
    Points
    25 676
    Par défaut V8, le moteur JavaScript de Google, est désormais plus léger avec 22 % de charge de mémoire en moins
    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.

    Nom : z1.png
Affichages : 49236
Taille : 36,6 Ko

    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).

    Nom : z1.png
Affichages : 4609
Taille : 18,7 Ko

    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.

    Nom : z1.png
Affichages : 4845
Taille : 27,1 Ko

    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    juillet 2013
    Messages
    1 206
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 206
    Points : 7 579
    Points
    7 579
    Billets dans le blog
    43
    Par défaut
    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).
    Tutoriels et FAQ TypeScript

  3. #3
    Membre actif
    Homme Profil pro
    Inscrit en
    septembre 2011
    Messages
    67
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : septembre 2011
    Messages : 67
    Points : 261
    Points
    261
    Par défaut
    Citation Envoyé par yahiko Voir le message
    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 ?

  4. #4
    Expert confirmé
    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2009
    Messages
    1 640
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2009
    Messages : 1 640
    Points : 4 107
    Points
    4 107
    Par défaut
    Citation Envoyé par yahiko Voir le message
    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++!

Discussions similaires

  1. Réponses: 6
    Dernier message: 28/11/2018, 21h52
  2. Étude : Google est le plus grand bénéficiaire du RGPD
    Par Stan Adkens dans le forum Actualités
    Réponses: 2
    Dernier message: 11/10/2018, 17h08
  3. Google est désormais un membre Platinum de la Linux Foundation
    Par Christian Olivier dans le forum Linux
    Réponses: 1
    Dernier message: 29/06/2018, 14h53
  4. Réponses: 5
    Dernier message: 07/11/2016, 10h23

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo