IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Mozilla ajoute un nouvel interpréteur JavaScript plus rapide dans Firefox 70
Et promet des gains de performance non négligeables avec le navigateur qui sortira en octobre

Le , par Olivier Famien

1.3KPARTAGES

21  0 
Il est de notoriété publique que les applications web modernes exécutent beaucoup plus de code JavaScript qu’il y a quelques années. Bien que les compilateurs Juste-à-temps (Just-In-Time en anglais) ont rapidement suivi la tendance et ont rendu JavaScript performant, pour Mozilla une solution doit être mise en place pour gérer cette charge de travail liée à l’usage omniprésent de JavaScript.

Pour se faire, Mozilla a développé et ajouté à un nouvel interpréteur de bytecode JavaScript à son moteur de rendu JavaScript intégré à Firefox 70. Avec Firefox 70 qui sera disponible en octobre prochain, Mozilla annonce donc une gestion plus performante du code JavaScript avec l’aide de son nouvel interpréteur de code ajouté à son moteur JavaScript.

Pour atteindre cet objectif, Mozilla explique que dans les moteurs JavaScript modernes, chaque fonction est initialement exécutée dans un interpréteur de code. Les fonctions qui sont beaucoup appelées sont compilées en code machine natif. Cela s’appelle la compilation JIT ou compilation à la volée. Pour ce qui concerne Firefox, il intègre également un interpréteur de code JavaScript écrit en C++ et plusieurs niveaux de compilation JIT. Dans un premier temps, nous avons d’abord un compilateur JIT de base qui compile chaque instruction bytecode directement en un petit morceau de code machine en utilisant la mise en cache inline à la fois pour des besoins de performance et de collecte des informations de type pour le compilateur JIT nommé IonMonkey ou Ion. À son tour, le compilateur IonMonkey utilise des optimisations avancées pour générer un code rapide pour les options critiques. Il faut préciser que lorsqu’une fonction déjà en cours de compilation est appelée avec un nouveau type d’arguments, le code de la fonction peut être « ;désoptimisé ;» et abandonné. Dans pareil cas, l’exécution se poursuit dans le code de base jusqu’à la prochaine compilation Ion.


Bien que ce processus d’interprétation du code JavaScript a fonctionné assez bien jusque-là, l’équipe de Firefox explique qu’elle a rencontré quelques problèmes avec la première partie du pipeline composée de l’interpréteur C++ et du compilateur JIT de base. En effet, certaines applications web modernes comme Google Docs ou encore Gmail exécutent tellement de code JavaScript que le compilateur de base et même le compilateur JIT pourraient passer beaucoup de temps en cherchant à compiler des milliers de fonctions. Par ailleurs, l’interpréteur C ++ s’est avéré très lent et ne collecte pas d’informations de type, ce qui retarde la compilation de base. Une solution aurait été de le déplacer hors du thread, mais cela aurait constitué un risque de performance. Pour résoudre ces problèmes, Firefox a ajouté au pipeline une nouvelle étape appelée interpréteur de base.


L’interpréteur de base se situe entre l’interpréteur C++ et le compilateur JIT de base et contient des éléments des deux niveaux. Il exécute toutes les instructions bytecode avec une boucle d’interpréteur fixe (comme l’interpréteur C++), et utilise les techniques de mise en cache inline pour améliorer les performances et collecter des informations de type (comme le JIT de base le fait). Générer un interprète n’est pas une nouvelle idée. Mais l’équipe de Firefox souligne ici qu’elle a trouvé un nouveau moyen de le faire en réutilisant la plus grande partie du code du compilateur JIT de base. Le compilateur JIT de base est un modèle de JIT, ce qui signifie que chaque instruction de code intermédiaire est compilée en une séquence d’instructions-machine essentiellement fixes qui sont ensuite suggérées dans une boucle d’interprétation.

En outre, vu que les développeurs de Firefox souhaitaient que l’interpréteur de base utilise exactement les mêmes caches inline et les mêmes informations que le JIT de base, une nouvelle structure de données appelée JitScript a été ajoutée. JitScript contient toutes les informations de type et les structures de données de mise en cache inline utilisées par les interpréteurs de base et le compilateur JIT. Avec ces nouvelles implémentations, les données du compilateur de base pour une fonction sont maintenant uniquement en code machine. À partir de là, toutes les informations mises en cache et les données de profilage ont été déplacées dans JitScript.

En sus, vu que l’interpréteur de base et le compilateur JIT sont identiques, une grande partie du code généré peut également être partagée. Pour ce faire, une classe de base nommée BaselineCodeGen a été créée avec 2 autres classes dérivées. La première classe BalineCompiler est utilisée par le compilateur de base pour compiler le bytecode d’un script en code machine. La seconde classe BaselineInterpreterGenerator est utilisée pour générer le code de l’interpréteur de base. Et avec la classe BaselineInterpreterGenerator, l’équipe de Firefox est parvenue à générer l’interpréteur de base.

Après avoir activé l’interpréteur de base dans Firefox Nightly (version 70) en juillet, l’équipe de Firefox a constaté plusieurs améliorations. Au niveau de la vitesse chargement par exemple, l’on est passé de 2 à 8 % en termes d’amélioration. Au niveau de l’utilisation de la mémoire, les développeurs de Firefox rapportent également des gains en ce qui concerne l’empreinte mémoire. De même, un test avec Google Docs a permis de révéler que le nouvel interpréteur de base est beaucoup plus rapide que l’interpréteur C++. L’activation du compilateur JIT accélère également le chargement de la page. Enfin, les développeurs de Firefox font remarquer que le temps de démarrage de l’interpréteur de base est beaucoup plus rapide que celui de l’interpréteur C++.

Source : Mozilla

Et vous ?

Avez-vous testé Firefox Nightly 70 avec le nouvel interpréteur de base pour JavaScript ?

Avez-vous noté un gain de performance dans le rendu des pages JavaScript ?

Voir aussi

Firefox 70 vous avertira quand vos identifiants et mots de passe enregistrés sont compromis suite à une violation de données répertoriée
Mozilla publie Firefox Quantum 68 et Firefox ESR 68 qui apportent des protections contre le cryptomining et le fingerprinting dans les préférences
Mozilla utilisera BITS et un agent de mise à jour dédié pour garder Firefox à jour sous Windows, même avec une connexion lente, à partir de Firefox 70
La part de marché de Firefox augmente pour la deuxième fois consécutive en 2 mois, le navigateur libre pourrait-il survivre auprès de Chrome ?
Windows 10 se rapproche de 50 % de part de marché, pendant que Chrome continue sa croissance, selon Netmarketshare

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 01/09/2019 à 23:11
Après quelques années de dispersion avec des projets relativement douteux comme Firefox Hello, ou Firefox OS, les voilà qui reviennent aux fondamentaux, à savoir leur navigateur.
Si ce nouvel interpréteur tient toutes ses promesses, peut-être que je me remettrai sur Firefox, après m'être résigné à utiliser Chrome.
Mais je constate déjà que l'écart de rapidité entre les deux navigateurs, flagrant il y a deux ans de cela, s'est considérablement réduit.
8  0 
Avatar de Zefling
Expert confirmé https://www.developpez.com
Le 01/09/2019 à 23:44
Citation Envoyé par yahiko Voir le message
Mais je constate déjà que l'écart de rapidité entre les deux navigateurs, flagrant il y a deux ans de cela, s'est considérablement réduit.
Franchement, utilisant Chrome et Firefox tous les jours au boulot. Chrome s'est sacrément ralenti, du coup, je ne sais pas si c'est Firefox qui est devenu plus rapide ou pas, mais maintenant pour le rendu, sur Firefox ça va plus vite. Par contre, c'est toujours côté JS que Firefox a un problème. Le débuggage JS/TS, sur des gros projets, est juste horrible à côté de Chrome.

Bref, Chrome s’encroûte, ce qui risque de donner un coup de pouce à Firefox : plus rapide sur le rendu, en avance sur pas mal de modules CSS, et s'il est au niveau de Chrome sur le JS, Chrome n'aura plus grand-chose d'intéressant.
5  0 
Avatar de Juzorcrayon
Futur Membre du Club https://www.developpez.com
Le 01/09/2019 à 4:19
Je fais confiance à Mozilla et ce nouvel interpréteur peut être bien plus rapide que prévu, merci de nous tenir informé !
4  0 
Avatar de rsuinux
Membre habitué https://www.developpez.com
Le 02/09/2019 à 7:42
En ce qui me concerne, j'ai mis un bloqueur de JavaScript, et c'est quand même vachement mieux ! Je n'active que ce qui est strictement nécessaire. C'est chiant, mais au bout d'un moment, ça va. La moitié en plus, c'est pour lla bub (pardon "les partenaires"
Quand vous avez une page avec 40 scripts, c'est sur que le navigateur doit être optimisé.
6  2 
Avatar de emilie77
Membre éprouvé https://www.developpez.com
Le 02/09/2019 à 8:18
Moi aussi bloqueur de Js et desactivé seulement s'il le faut
2  1 
Avatar de weed
Membre expérimenté https://www.developpez.com
Le 02/09/2019 à 23:32
Citation Envoyé par yahiko Voir le message
Si ce nouvel interpréteur tient toutes ses promesses, peut-être que je me remettrai sur Firefox, après m'être résigné à utiliser Chrome.
Mais je constate déjà que l'écart de rapidité entre les deux navigateurs, flagrant il y a deux ans de cela, s'est considérablement réduit.
Pourquoi continues tu d'utiliser Chrome? A moins que je me trompes, il y a eu pas mal de tests et il semblerait qu'en terme de rapidité et de consommation, cela se joue à pas grand chose. Sur certains points, Firefox est même plus efficace que Chrome.

Selon moi, le critère de rapidité n'est plus en faveur de Chrome. Autre avantage de Firefox, le respect de la vie privée et de son indépendance avec son moteur de rendu.

Peut être que tu continues à utilChrome plutôt par habitudes a performance égal. Il faudrait qu'il y ait un gros gap de performance pour te faire changer d'avis.

Et malheureusement je pense qu'il y a pas mal de personnes dans ton cas, et malgré les efforts de la fondation tout faire pour reprendre quelques parts de marché (améliorations des perf, de la conso, mise en avant de la vie privée), elle n'y arrive pas. La fondation se retrouve dans une impasse.
1  0 
Avatar de chinagirl
Membre du Club https://www.developpez.com
Le 04/09/2019 à 20:46
Moi ce que j'aimerais c'est que les performances de traitement du SVG s'améliorent. Il y a une différence significative avec Chrome.
0  0 
Avatar de ddoumeche
Membre extrêmement actif https://www.developpez.com
Le 26/09/2019 à 21:20
Citation Envoyé par chinagirl Voir le message
Moi ce que j'aimerais c'est que les performances de traitement du SVG s'améliorent. Il y a une différence significative avec Chrome.
Voeux pieux. pourquoi ne pas servir directement des images avec éventuellement une légère touche de javascript surimposée pour tout ce qui est dynamique.
0  0 
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 03/09/2019 à 0:00
Pour le moment, j'ai encore l'impression que Chrome est plus rapide pour la navigation lambda généraliste.
Peut-être ai je tort et que des benchmarks démontrent le contraire. Aussi, pour le développement responsive, je trouve les dev tools de Chrome plus pratiques à mon goût. Notamment l'émulation des différents formats de devices.
Quand à la vie privée, ça reste un critère secondaire par rapport à la productivité.
J'utilise Firefox de manière régulière mais nettement moins intensive que Chrome. Ce que je peux dire, c'est que ça va dans le bon sens. Surtout encore une fois si leur moteur Spidermonkey un peu antédiluvien venait à se refaire une jeunesse.
0  2