メインコンテンツまでスキップ

実際のパフォーマンス測定に関するV8の方法

· 約8分
V8チーム

昨年、V8チームは実際のJavaScriptパフォーマンスを測定および理解するための新しい方法論を開発しました。それによって得られる洞察を活用して、JavaScriptをより速くする方法を変更しました。この新しい実践的な焦点は、従来の性能への焦点から大きな変化を遂げています。この方法論を2017年にも適用し続けることで、ChromeやNode.jsにおける実際のJavaScriptの予測可能なパフォーマンスに対するユーザーと開発者の信頼性を大幅に向上させると確信しています。

「測定されたものは改善される」という古い格言は、JavaScript仮想マシン（VM）開発の世界では特に当てはまります。性能最適化を導くための適切な指標を選ぶことは、VMチームが時間をかけて行う最も重要なことの1つです。以下のタイムラインは、V8の初期リリース以来、JavaScriptベンチマーキングがどのように進化してきたかを大まかに示しています。

JavaScriptベンチマークの進化

これまで、V8や他のJavaScriptエンジンは合成ベンチマークを使用して性能を測定してきました。当初、VM開発者はSunSpiderやKrakenなどのマイクロベンチマークを使用していました。ブラウザ市場が成熟すると、第2のベンチマーキング時代が始まり、OctaneやJetStreamなどの、より大きな合成テストスイートを使用するようになりました。

マイクロベンチマークと静的テストスイートにはいくつかの利点があります。設定が簡単で、理解しやすく、どのブラウザでも実行できるため、比較分析が容易です。しかし、この利便性にはいくつかの欠点も伴います。テストケースの数が限られているため、ウェブ全体の特性を正確に反映するベンチマークを設計するのは困難です。また、ベンチマークは通常あまり更新されないため、実際のJavaScript開発の新しいトレンドやパターンに対応するのが難しくなりがちです。さらに、従来のベンチマークの隅々まで探求された結果、ベンチマークの実行中に外部で観察されない仕事を入れ替えたりスキップしたりして、スコアを向上させる機会を利用しました。このようなベンチマークスコア主導の改善やベンチマークに過度に最適化することは、ユーザーや開発者に直接的な利益をもたらすことが少なく、長期的には「ゲームができない」合成ベンチマークを作るのが非常に難しいことが歴史的に証明されています。

実際のウェブサイトを測定する: WebPageReplay & Runtime Call Stats​

従来の静的ベンチマークではパフォーマンスストーリーの一部しか見えていないという直感をもとに、V8チームは実際のウェブサイトの読み込みをベンチマークして実際の性能を測定することに乗り出しました。我々は、エンドユーザーが実際にウェブをどのように閲覧しているかを反映するユースケースを測定したいと考え、Twitter、Facebook、Google Mapsなどのウェブサイトから性能指標を導き出すことにしました。Chromeインフラストラクチャの一部であるWebPageReplayを使用して、ページの読み込みを記録し、それを決定論的に再生することができました。

同時に、Runtime Call Statsというツールを開発し、異なるJavaScriptコードが異なるV8コンポーネントにどのように負荷をかけるかをプロファイルすることができました。我々は初めて、実際のウェブサイトを簡単にテストし、V8が異なる作業負荷の下でどのように、またなぜ異なる性能を持つのかを完全に理解することができました。

現在、約25のウェブサイトのテストスイートに対する変更を監視し、V8最適化を導いています。先述したウェブサイトやAlexaトップ100からの他のウェブサイトに加えて、一般的なフレームワーク（React、Polymer、Angular、Emberなど）を使用して実装されたサイト、さまざまな地理的地域のサイト、Wikipedia、Reddit、Twitter、Webpackなど、開発チームが協力してくれたサイトやライブラリも選定しました。これら25のサイトは、ウェブ全体を代表していると考えており、これらのサイトの性能改善が今日JavaScript開発者によって書かれているサイトの類似した高速化に直接反映されると信じています。

ウェブサイトのテストスイートとRuntime Call Statsの開発に関する深掘りプレゼンテーションについては、実際のパフォーマンスに関するBlinkOn 6プレゼンテーションをご覧ください。また、自分でRuntime Call Statsツールを実行することもできます。

実際の効果を生む​

これらの新しい実世界のパフォーマンス指標を分析し、従来のベンチマークとRuntime Call Statsを用いて比較することで、さまざまなワークロードがどのように異なる方法でV8に負担をかけるかについて、より深い洞察を得ることができました。

これらの測定結果から、テストした25のウェブサイトの大半において、Octaneのパフォーマンスが実際のパフォーマンスを正しく反映していないことが判明しました。以下のグラフで確認できますが、Octaneの色分布は他のワークロード、特に実世界のウェブサイトのものとは大きく異なります。Octaneを実行するとき、V8のボトルネックはしばしばJavaScriptコードの実行にありますが、ほとんどの実世界のウェブサイトではむしろV8のパーサーやコンパイラーがストレスを受けています。Octaneに向けた最適化は、往々にして実世界のウェブページにはほとんど影響を与えず、場合によっては実世界のウェブサイトを遅くすることさえあります。

Octane全体の実行時間、Speedometerの行項目の実行時間、テストスイート内のウェブサイトの読み込み時間の分布（Chrome 57での測定結果）

さらに、別のベンチマークが実際のウェブサイトをより正確に反映していることも発見しました。Speedometerは、React、Angular、Emberなどのフレームワークで書かれたアプリケーションを含むWebKitベンチマークであり、25のサイトと非常に似た実行プロファイルを示しました。どのベンチマークも実際のウェブページの正確さに完全に一致するわけではありませんが、SpeedometerはOctaneよりも現代のJavaScriptの実世界のワークロードをより的確に近似していると私たちは考えています。

結論：すべての人に高速なV8を​

過去1年間、実世界のウェブサイトテストスイートとRuntime Call Statsツールを活用した結果、ページの読み込み時間を平均で10-20%短縮するV8のパフォーマンス最適化を実現しました。Chromeにおけるページ読み込み最適化への長年の注力を考えると、2016年にメトリクスを2桁向上させたことは大きな成果と言えます。同じ最適化により、Speedometerでのスコアも20-30%改善しました。

これらのパフォーマンス改善は、モダンなフレームワークと同様のJavaScriptパターンを使用するウェブ開発者によって書かれた他のウェブサイトにも反映されるはずです。例えば、Object.createやFunction.prototype.bindのようなビルトインの改善、オブジェクトファクトリーパターンに関連する最適化、V8のインラインキャッシュの改良、そして継続的なパーサー改善などは、追跡中の代表的なサイトだけでなく、すべての開発者が使用するJavaScriptの見過ごされがちな領域に対する一般的な改善を意図したものです。

実世界のウェブサイトを活用してV8パフォーマンス作業をさらに進めていく予定です。ベンチマークやスクリプトパフォーマンスについてのさらなる洞察にご期待ください。