10 Posts getaggt mit "JavaScript"

Ein schnelles Starten von JavaScript ist entscheidend für eine reaktionsschnelle Web-App. Selbst mit den fortgeschrittenen Optimierungen von V8 können Parsing und Kompilierung von kritischem JavaScript während des Startvorgangs weiterhin Leistungseinbußen verursachen. Wenn bekannt ist, welche JavaScript-Funktionen während der initialen Skriptkompilierung kompiliert werden sollen, kann dies das Laden von Webseiten beschleunigen.

Der endstufige optimierende Compiler von V8, Turbofan, ist bekanntlich einer der wenigen großflächig eingesetzten Produktions-Compiler, die Sea of Nodes (SoN) verwenden. Jedoch haben wir vor fast 3 Jahren begonnen, Sea of Nodes loszuwerden und stattdessen auf eine traditionellere Control-Flow Graph (CFG) Intermediate Representation (IR) zurückzugreifen, die wir Turboshaft genannt haben. Mittlerweile nutzt der gesamte JavaScript-Backend von Turbofan Turboshaft, und WebAssembly verwendet Turboshaft in seiner gesamten Pipeline. Zwei Teile von Turbofan benutzen weiterhin Sea of Nodes: die eingebaute Pipeline, die wir langsam durch Turboshaft ersetzen, und die Frontend-Pipeline von JavaScript, die wir durch Maglev, eine weitere auf CFG basierende IR, ersetzen. In diesem Blogbeitrag erklären wir die Gründe, die uns dazu geführt haben, vom Meer der Knoten wegzugehen.

Bei V8 streben wir ständig danach, die Leistung von JavaScript zu verbessern. Im Rahmen dieser Bemühungen haben wir kürzlich die JetStream2-Benchmark-Suite geprüft, um Leistungseinbrüche zu beseitigen. Dieser Beitrag beschreibt eine spezifische Optimierung, die eine signifikante Verbesserung von 2.5x im async-fs-Benchmark ergab und zu einem spürbaren Anstieg der Gesamtpunktzahl beitrug. Die Optimierung wurde durch den Benchmark inspiriert, aber solche Muster finden sich auch im echten Code.

Haben Sie sich jemals gefragt, woher undefined, true und andere zentrale JavaScript-Objekte stammen? Diese Objekte sind die Atome eines jeden benutzerdefinierten Objekts und müssen zuerst vorhanden sein. V8 nennt sie unbewegliche, unveränderliche Wurzeln, und sie befinden sich in ihrem eigenen Heap – dem schreibgeschützten Heap. Da sie ständig verwendet werden, ist ein schneller Zugriff entscheidend. Und was könnte schneller sein, als ihre Speicheradresse zur Kompilierungszeit korrekt zu erraten?

Willkommen in der spannenden Welt von V8, wo Geschwindigkeit nicht nur ein Feature, sondern eine Lebensweise ist. Während wir uns von 2023 verabschieden, ist es Zeit, die beeindruckenden Errungenschaften zu feiern, die V8 in diesem Jahr erreicht hat.

Durch innovative Leistungsoptimierungen erweitert V8 weiterhin die Grenzen des Möglichen in der sich ständig weiterentwickelnden Weblandschaft. Wir haben einen neuen Mitteltier-Compiler eingeführt und mehrere Verbesserungen an der Top-Tier-Compiler-Infrastruktur, der Laufzeitumgebung und dem Garbage Collector implementiert, was zu signifikanten Geschwindigkeitsgewinnen auf allen Ebenen geführt hat.

In Chrome M117 haben wir einen neuen optimierenden Compiler eingeführt: Maglev. Maglev liegt zwischen unseren bestehenden Sparkplug- und TurboFan-Compilern und übernimmt die Rolle eines schnellen optimierenden Compilers, der schnell genug guten Code generiert.

Bis 2021 hatte V8 zwei Hauptausführungsstufen: Ignition, den Interpreter; und TurboFan, den auf Spitzenleistung fokussierten optimierenden Compiler von V8. Alle JavaScript-Code wird zunächst in Ignition-Bytecode kompiliert und durch Interpretation ausgeführt. Während der Ausführung verfolgt V8, wie sich das Programm verhält, einschließlich der Verfolgung von Objektformen und -typen. Sowohl die Metadaten der Laufzeitausführung als auch der Bytecode werden in den optimierenden Compiler eingespeist, um hochleistungsfähigen, oft spekulativen Maschinencode zu generieren, der deutlich schneller läuft als der Interpreter.

In V8 v9.1 haben wir die eingebetteten Builtins vorübergehend auf Desktop deaktiviert. Obwohl das Einbetten von Builtins die Speichernutzung erheblich verbessert, haben wir festgestellt, dass Funktionsaufrufe zwischen eingebetteten Builtins und JIT-kompiliertem Code zu erheblichen Leistungseinbußen führen können. Diese Kosten hängen von der Mikroarchitektur der CPU ab. In diesem Beitrag erklären wir, warum dies passiert, wie die Leistung aussieht und was wir planen, um dieses Problem langfristig zu lösen.

Das super-Schlüsselwort kann verwendet werden, um auf Eigenschaften und Funktionen des Elternobjekts eines Objekts zuzugreifen.

Früher wurde der Zugriff auf eine Super-Eigenschaft (wie super.x) über einen Laufzeitaufruf umgesetzt. Ab V8 v9.0 verwenden wir das Inline-Cache-System (IC) in nicht-optimiertem Code und generieren den entsprechenden optimierten Code für den Zugriff auf Super-Eigenschaften, ohne zur Laufzeit springen zu müssen.

Einführung​

Dank der jüngsten Arbeit in Chrome und Emscripten können Sie jetzt bis zu 4 GB Speicher in WebAssembly-Anwendungen nutzen. Das ist eine Steigerung gegenüber dem vorherigen Limit von 2 GB. Es mag seltsam erscheinen, dass es jemals ein Limit gab – schließlich war keine Arbeit notwendig, damit Menschen 512 MB oder 1 GB Speicher nutzen konnten! – aber es stellt sich heraus, dass beim Sprung von 2 GB auf 4 GB sowohl im Browser als auch in der Werkzeugkette einige besondere Dinge geschehen, die wir in diesem Beitrag beschreiben werden.