Chrome 50 embarquera la version 5.0 du moteur JavaScript V8

Chrome 50 embarquera la version 5.0 du moteur JavaScript V8

De la compatibilité et des performances

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

16/03/2016 3 minutes
20

Chrome 50 embarquera la version 5.0 du moteur JavaScript V8

Chrome 50 sera une version majeure du navigateur. Google a en effet décidé d’y intégrer la version 5.0 de son moteur JavaScript. Une évolution importante, tant sur le plan de la sécurité que celui des performances.

Le moteur JavaScript d’un navigateur est devenu un composant crucial avec la modernisation du web. Le JavaScript, comme tout langage de script, doit en effet être analysé, interprété et compilé pour pouvoir être exécuté. Avec le temps, l’utilisation de ce langage a créé le besoin d’avoir un composant entièrement dédié à ces opérations, pour laisser le processus principal s’occuper du rendu lui-même.

Une version pas si majeure pour Google

Il existe une guerre des machines virtuelles JavaScript, comme il existe des guerres pour les moteurs de rendu et donc pour les navigateurs. Chez Google, la machine virtuelle se nomme V8 et elle s’est signalée dès son apparition par des performances qui ont largement participé à la réputation de Chrome dans ce domaine. Elle a évolué avec le temps et se prépare à franchir nouvelle étape avec l’arrivée d’une version 5.0.

Or, Google a annoncé hier que cette nouvelle mouture serait bien présente dans Chrome 50, qui devrait être diffusé dans environ un mois. Pour un chiffre aussi rond et symbolique, le navigateur se dote donc d’une importante nouveauté qui marquera davantage les esprits que la plupart des précédentes versions. Il indique cependant qu’en dépit de son numéro, V8 5.0 n’est pas forcément à considérer comme majeure, la nomenclature évoluant un peu de la même manière que le noyau Linux.

Compatibilité ECMAScript 2015 et performances

Et pourtant, elle contient une longue liste d’améliorations, en particulier pour les développeurs. Premier point : un renforcement important de la compatibilité avec la norme ECMASCript 2015, anciennement ECMASCript 6. V8 peut ainsi gérer les flags RegExp Unicode et ajoute des crochets de personnalisation pour les sous-classes RegExp.

À nouvelle version, nouvelle amélioration des performances. Ce sera particulièrement le cas pour les implémentations de paramètres « rest », dont Google annonce qu’elles sont huit à dix fois plus rapides que dans la version précédente, les rendant plus efficaces pour rassembler un grand nombre d’arguments dans un tableau unique après un appel de fonction. La méthode Object.keys(), qui renvoie un tableau des propriétés propres à un objet, se veut de son côté deux fois plus rapide. Du côté des API, rien ne change vraiment par contre.

Du tout bon pour l'internaute

Google a dans tous les cas intérêt à ne surtout pas se laisser distancer sur ce terrain. Microsoft galope avec Chakra, son propre moteur JavaScript, l’éditeur mettant surtout en avant ses performances et son respect du standard ECMAScript., tout en l'ayant passé à l'open source. L’utilisation du JavaScript n’étant clairement pas amenée à diminuer (au contraire), l’affrontement ne va que pouvoir s’intensifier. Principal bénéficiaire de cette concurrence ? L’internaute.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Une version pas si majeure pour Google

Compatibilité ECMAScript 2015 et performances

Du tout bon pour l'internaute

Fermer

Commentaires (20)


Excellent article. Bien résumé et bien expliqué.

Comme dirait Léonard de Vinci : “La simplicité est le summum de la qualité” (ce n’est pas la citation exacte :p).


Je sais pas pour vous, mais je trouve Chrome de plus en plus lent et gourmand en ressources. J’ai pourtant pas beaucoup d’extensions de chargées, et toujours au gros max 15 onglets ouverts. 

Quand j’ouvre Firefox à côté c’est vraiment le jour et la nuit… 

Enfin si déjà ils rendent le javascript plus rapide, c’est bien.


<img data-src=" />


Tu devrais tenter en désactivant les extensions, le nombre importe peu, il suffit d’une seule <img data-src=" />



Perso j’ai l’impression que Chrome galère un peu quand on commence à avoir un historique bien chargé (milliers de bookmarks / formulaires / recherches etc.) mais difficile de comparer avec un autre navigateur du coup :/




Le JavaScript, comme tout langage de script, doit en effet être analysé, interprété et compilé pour pouvoir être exécuté.



Non, le JavaScript n’est pas (encore) compilé.


Bon je sais que ça ressort à chaque fois et tout mais… Lire “Chrome 50” m’a fait rire tellement ce numéro de version est ridicule.



Chrome 50, 10% plus rapide que Chrome 48 et jusqu’à 30% plus rapide que Chrome 34 ! Bien sûr tout le monde de rappelle à quel point la version 34 était lente… Ou était-ce la 35 ? Ou la 26 ?



Bref, c’est ridicule. Il en va de même pour firefox 46, au passage.








Tekikou a écrit :



Non, le JavaScript n’est pas (encore) compilé.





&nbsp;Tout dépend ta définition de compilé, mais globalement si, Les moteurs modernes compilent une partie du Javascript en langage machine à la volée pendant l’execution (JIT) s’ils estime que c’est un bout de code assez utilisé pour que le gain de performance vaille le temps de compilation, ou dès sont chargement(AOT) pour l’asm.js



Je pense qu’il voulait dire que la tournure “interprété et compilé” est à la limite de l’oxymore.


J’ai déjà essayé de virer toutes les extensions, même galère.

Ça rame à ouvrir une nouvelle page (nouvelle onglet), et même desfois ça load jamais, obligé de relancer le browser.

Je pense aussi que l’historique doit jouer, je le vide jamais donc depuis le temps ça doit être assez gros. Par contre je vide le cache de temps en temps. Enfin ça reste jamais qu’une liste d’url / date, même une base sqlite devrait pas trop galérer à gérer tout ça…


Sauf que pour le coup, c’est bien se qui se passe. Le Javascript est, dans un premier temps, interprété. Ensuite, lors de l’exécution, les sections qui sont le plus sollicitées seront compilées en code natif.


Au fait, des nouvelles sur l’avancement vers une version stable de Vivaldi et d’OtterBrowser (tous deux faisant appel à Blink) ?


Ce qui est intéressant c’est aussi l’amélioration prochaine des performances du côté des serveurs utilisant nodejs lorsque ce dernier intégrera la nouvelle version de v8 dans une release considérée stable.


Tu as raison ça ressort à chaque fois donc abstient toi la prochaine fois…



Une dernière fois pour ce qui ne comprennent pas ce genre d’évolution rapide (et ça concerne Chrome, Firefox, les builds Windows, Linux etc) : ce numéro n’est pas là pour l’utilisateur lambda mais pour les développeurs et journaliste spécialisé !!



Quand Google fait de la promo pour Chrome il le fait pour Chrome et pas pour Chrome 50.. De toute façon les majs sont automatiques et il y a peu de fragmentation donc tous le monde est sur du Chrome &gt; 48 .. Par contre pour un dev savoir que son site s’affiche bien en 49 mais plus en 50 est utile.



Sérieusement, les commentaires ne sont pas une poubelle, réfléchissez avant de poster… Lire un même truc idiot pendant des années sur chaque news d’un même sujet ça devient vraiment pénible. NXI est censé être un site technophiles avec un public averti mais ça devient de plus en plus un clubic ou jeuxvideo.com bis…


Non. Ca c’était la technique de “HotSpot”, la VM de Sun pour Java.



“V8 compiles JavaScript source code directly into machine code when it is first executed.”



https://developers.google.com/v8/design#dynamic-machine-code-generation


Autant pour moi, après vérification V8 compile bien systématiquement, même si par défaut il compile du code pas du tout optimisé.



Ça m’a surpris car, Hotspot n’est pas le seul a faire ça, les autres moteurs JavaScript font ça également, vu que sur les portions de codes qui ne sont exécutés que peux de fois, le gain de vitesse n’est généralement pas rentable par rapport au temps passé à la compilation.



Visiblement, V8 génère par défaut du code pas du tout optimisé mais qui se compile très vite et il optimise a la volée les sections critique. Bref au final ça revient a peu près au même au niveau du fonctionnement a plusieurs niveaux.








Vengeful-frog a écrit :



Au fait, des nouvelles sur l’avancement vers une version stable de Vivaldi et d’OtterBrowser (tous deux faisant appel à Blink) ?





Pour Vivaldi (1.0, pour celles et ceux qui n’aiment pas avoir la plus grosse), c’est prévu au… printemps&nbsp;<img data-src=" />



Merci. ^^


Et on ne peut toujours pas l’installer ailleurs que sur le disque c:&nbsp; ?


J’avoue ce n’est qu’un numéro de version, le tout sur un seul nombre. Facile à retenir et à comparer, bref je vois pas pourquoi se prendre la tête avec ça.








arno53 a écrit :



Tu as raison ça ressort à chaque fois donc abstient toi la prochaine fois…



Une dernière fois pour ce qui ne comprennent pas ce genre d’évolution rapide (et ça concerne Chrome, Firefox, les builds Windows, Linux etc) : ce numéro n’est pas là pour l’utilisateur lambda mais pour les développeurs et journaliste spécialisé !!



Quand Google fait de la promo pour Chrome il le fait pour Chrome et pas pour Chrome 50.. De toute façon les majs sont automatiques et il y a peu de fragmentation donc tous le monde est sur du Chrome &gt; 48 .. Par contre pour un dev savoir que son site s’affiche bien en 49 mais plus en 50 est utile.



Sérieusement, les commentaires ne sont pas une poubelle, réfléchissez avant de poster… Lire un même truc idiot pendant des années sur chaque news d’un même sujet ça devient vraiment pénible. NXI est censé être un site technophiles avec un public averti mais ça devient de plus en plus un clubic ou jeuxvideo.com bis…





Non mais regardez-le celui-là avec son arrogance. Tu te crois supérieur parce que tu aimes ces gros chiffres ridicules ?

&nbsp;

Je

me fiche la façon dont Google et Mozilla communiquent avec le grand

public. En tant qu’utilisateur / développeur, j’aime bien une

numérotation cohérente et représentative des avancées. Par exemple,

Firefox 3 -&gt; 4 je savais que les changement étaient nombreux et majeurs.

J’ai donc passé davantage de temps à tester le passage 3 -4 que 3.0 et

3.1. Ce qui est logique.



Désormais je dois me farcir les

changelogs et les déchiffrer pour déterminer si les changements proposés

sont majeurs et affectent mes sites. Ou alors compter sur PCI pour le

faire&nbsp; à ma place. Désolé, mais j’ai mieux à faire.



Donc je ré-affirme mon désaccord avec cette numérotation que je trouve toujours ridicule, et ce malgré ton commentaire.