10 articles tagués avec « JavaScript »

Faire fonctionner JavaScript rapidement est essentiel pour une application web réactive. Même avec les optimisations avancées de V8, analyser et compiler le JavaScript critique lors du démarrage peut toujours être une source de ralentissements. Savoir quelles fonctions JavaScript compiler lors de la compilation initiale du script peut accélérer le chargement de la page web.

Le compilateur optimisant de V8, Turbofan, est renommé pour être l’un des rares compilateurs de production à grande échelle à utiliser Sea of Nodes (SoN). Cependant, depuis près de 3 ans, nous avons commencé à nous débarrasser de Sea of Nodes et à revenir à une représentation intermédiaire (IR) plus traditionnelle avec le Control-Flow Graph (CFG), que nous avons nommé Turboshaft. Aujourd’hui, tout le backend JavaScript de Turbofan utilise Turboshaft, et WebAssembly utilise Turboshaft tout au long de son pipeline. Deux parties de Turbofan utilisent encore la mer des nœuds : le pipeline intégré, que nous remplaçons progressivement par Turboshaft, et le frontend du pipeline JavaScript, que nous remplaçons par Maglev, une autre IR basée sur CFG. Ce post explique les raisons qui nous ont poussés à abandonner la mer des nœuds.

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.

Vous êtes-vous déjà demandé d’où viennent undefined, true et les autres objets fondamentaux de JavaScript ? Ces objets sont les atomes de tout objet défini par l'utilisateur et doivent exister en premier. V8 les appelle racines immuables immobiles et ils résident dans leur propre tas – le tas en lecture seule. Étant constamment utilisés, un accès rapide est crucial. Et quoi de plus rapide que de deviner correctement leur adresse mémoire au moment de la compilation ?

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.

Dans Chrome M117, nous avons introduit un nouveau compilateur d’optimisation : Maglev. Maglev se situe entre nos compilateurs existants Sparkplug et TurboFan, et joue le rôle d’un compilateur rapide d’optimisation qui génère un code suffisamment performant de manière suffisamment rapide.

Jusqu'en 2021, V8 avait deux principaux niveaux d'exécution : Ignition, l'interpréteur ; et TurboFan, le compilateur d'optimisation de V8 axé sur les performances maximales. Tout le code JavaScript est d'abord compilé en bytecode Ignition, puis exécuté par interprétation. Pendant l'exécution, V8 suit le comportement du programme, y compris les formes et types des objets. Les métadonnées d'exécution et le bytecode sont ensuite utilisés par le compilateur d'optimisation pour générer un code machine performant, souvent spéculatif, qui s'exécute beaucoup plus rapidement que l'interpréteur.

Dans V8 v9.1, nous avons temporairement désactivé les fonctionnalités intégrées sur le bureau. Bien que l'intégration des fonctionnalités améliore significativement l'utilisation de la mémoire, nous avons remarqué que les appels de fonction entre les fonctions intégrées et le code compilé JIT peuvent entraîner une pénalité de performance considérable. Ce coût dépend de la microarchitecture du processeur. Dans ce post, nous expliquerons pourquoi cela se produit, à quoi ressemblent les performances et ce que nous prévoyons de faire pour résoudre ce problème à long terme.

Le mot-clé super peut être utilisé pour accéder aux propriétés et fonctions présentes sur l'objet parent.

Auparavant, l'accès à une propriété super (comme super.x) était implémenté via un appel au runtime. À partir de V8 v9.0, nous réutilisons le système de cache en ligne (IC) dans le code non optimisé et générons le code optimisé approprié pour l'accès aux propriétés super, sans avoir à appeler le runtime.

Introduction​

Grâce à des travaux récents sur Chrome et Emscripten, vous pouvez désormais utiliser jusqu'à 4 Go de mémoire dans les applications WebAssembly. C'est une augmentation par rapport à la limite précédente de 2 Go. Cela peut sembler étrange qu'il y ait eu une limite - après tout, aucun travail n'était nécessaire pour permettre aux gens d'utiliser 512 Mo ou 1 Go de mémoire ! - mais il s'avère qu'il y a des aspects spéciaux concernant le passage de 2 Go à 4 Go, à la fois dans le navigateur et dans la chaîne d'outils, que nous décrirons dans cet article.