可変ヒープ数でV8をターボチャージ
V8では、JavaScriptのパフォーマンス向上に常に努めています。この努力の一環として、最近JetStream2のベンチマークスイートを見直し、パフォーマンスの問題を解消しました。この投稿では、async-fs
ベンチマークで大幅な2.5倍
の改善を達成し、全体スコアに著しい向上をもたらした特定の最適化について詳しく説明します。この最適化はベンチマークから着想を得ましたが、実際のコードでも類似のパターンが見られます。
V8では、JavaScriptのパフォーマンス向上に常に努めています。この努力の一環として、最近JetStream2のベンチマークスイートを見直し、パフォーマンスの問題を解消しました。この投稿では、async-fs
ベンチマークで大幅な2.5倍
の改善を達成し、全体スコアに著しい向上をもたらした特定の最適化について詳しく説明します。この最適化はベンチマークから着想を得ましたが、実際のコードでも類似のパターンが見られます。
速さが単なる特徴ではなく、生活の一部である刺激的なV8の世界へようこそ。2023年を締めくくるにあたり、今年達成したV8の印象的な成果を祝う時が来ました。
革新的なパフォーマンス最適化を通じて、V8はWebの進化し続ける景観において可能な限界を押し広げ続けています。今年は、新しい中間層コンパイラを導入し、上位層コンパイラのインフラストラクチャ、ランタイム、ガベージコレクタにいくつかの改善を実施しました。その結果、広範囲で大幅な速度向上が実現しました。
Hai DangはV8チームでの3か月間のインターンシップ中に、[...array]
, [...string]
, [...set]
, [...map.keys()]
, および [...map.values()]
(配列リテラルの最初にスプレッド要素がある場合)のパフォーマンスを改善しました。さらに、Array.from(iterable)
の速度も大幅に向上させました。この記事では、彼の変更の詳細について説明します。これらの変更はv7.2以降のV8に含まれています。
JavaScriptにおける非同期処理は従来、特に速いとは言えないレピュテーションを持っていました。さらに悪いことに、ライブJavaScriptアプリケーション、特にNode.jsサーバーのデバッグは簡単ではありません。特に 非同期プログラミングに関してはそうです。しかし、時代は変わりつつあります。本記事では、V8で非同期関数とプロミスをどのように最適化したか(そしてある程度は他のJavaScriptエンジンでも)、および非同期コードのデバッグ体験をどのように改善したかを探ります。
DataView
sは、JavaScriptで低レベルメモリアクセスを行うための2つの可能な方法の1つです。もう1つはTypedArray
sです。これまで、V8においてTypedArray
sはDataView
sよりもかなり最適化されており、グラフィックス集約ワークロードやバイナリデータのデコード/エンコードなどの作業において低いパフォーマンスを示していました。この理由の多くは歴史的な選択に起因しています。例えば、asm.jsがDataView
sではなくTypedArray
sを選択していたことにより、エンジンがTypedArray
sのパフォーマンスに焦点を当てるよう促されていました。
今月は、Google Chromeだけでなく、V8プロジェクトも出荷開始から10周年を迎えます。この投稿では、V8プロジェクトの過去10年間の主なマイルストーン、およびプロジェクトがまだ秘密であったころの出来事を概観します。
Speedometer 1.0が2014年にリリースされて以来、BlinkとV8チームはこのベンチマークを人気のJavaScriptフレームワークの実際の使用状況の代理として活用し、ベンチマーク上で大幅な性能向上を達成しました。これらの改善が実際のユーザーに利益をもたらしていることを確認するため、実際のウェブサイトを測定したところ、人気のウェブサイトのページロード時間が改善されることでSpeedometerスコアも向上することを観察しました。
JavaScriptのパフォーマンスは常にV8チームにとって重要な課題であり、この投稿では最近使用している新しいJavaScriptWeb Tooling Benchmarkについて説明し、V8のパフォーマンスボトルネックを特定および修正する方法を共有します。既にご存じの方もいるかもしれませんが、V8はNode.jsに対する強いコミットメントを持っており、このベンチマークは特にNode.jsに基づいて構築された一般的な開発者ツールを使ったパフォーマンステストを実施することでそのコミットメントを拡張しています。Web Tooling Benchmarkに含まれるツールは、現代的なウェブサイトやクラウドベースのアプリケーションを構築するために、開発者やデザイナーが現在使用しているものと同じです。実際のパフォーマンスに焦点を合わせる現在進行中の取り組みを継続するために、開発者が毎日実際に使用するコードを基にベンチマークを作成しました。
プロキシは、ES2015以来JavaScriptの重要な部分を形成しています。これらはオブジェクトの基本操作をインターセプトし、その挙動をカスタマイズすることを可能にします。プロキシは、jsdomやComlink RPCライブラリのようなプロジェクトのコア部分を形成しています。最近、V8でプロキシのパフォーマンスを向上させるために多くの努力を行いました。この記事では、V8の一般的なパフォーマンス改善パターンについて、特にプロキシに関する内容を解説します。
JavaScriptベンチマークの歴史は、絶え間ない進化の物語です。ウェブが単純な文書から動的なクライアントサイドアプリケーションへと拡張するにつれて、新しいJavaScriptベンチマークが作成され、新しいユースケースで重要なワークロードを測定するようになりました。この絶え間ない変化により、個々のベンチマークは有限の寿命を持つようになりました。ウェブブラウザや仮想マシン(VM)の実装が特定のテストケースに過度に最適化し始めると、ベンチマーク自体が元のユースケースの有効な代替物でなくなります。最初期のJavaScriptベンチマークの一つであるSunSpiderは、初期の迅速な最適化コンパイラの提供にインセンティブを与えました。しかし、VMエンジニアがマイクロベンチマークの限界を発見し、最適化する新しい方法を見つけた結果、ブラウザコミュニティは推奨ベンチマークとしてSunSpiderの廃止を決定しました。