Quantcast
Viewing all articles
Browse latest Browse all 2206

Chrome が Speedometer 3 史上最高スコアを達成

この記事は Thomas Nattestad による Chromium Blog の記事 "How Chrome achieved the highest score ever on Speedometer 3"を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。



今回の「速さと好奇心」の投稿では、Chrome がどのようにして Speedometer 3.0 の史上最高スコアをたたき出したのかについて紹介します。Speedometer 3.0 は、アップグレードされた新しいブラウザ ベンチマーク ツールで、ウェブ アプリケーションのパフォーマンス最適化に役立ちます。今すぐ Chrome をお試しください。 

先日公開された Speedometer 3.0 は、ブラウザのパフォーマンスを測定するためのベンチマークで、企業を超えた業界全体のコラボレーションとして、Google、Apple、Mozilla、Intel、Microsoft などが作成したものです。Chrome を最適化し、すべてのユーザーのブラウザ エクスペリエンスを高速化できる領域を特定する際に役立ったのが、このベンチマークでした。

この更新版のベンチマークが開発されている間に、最新の Chrome のパフォーマンス情報をじっくりと慎重に追跡し、さらに最適化を進めることで、Speedometer 3 の史上最高のスコアをたたき出すことができました。ここでは、その手法について詳しく説明します。2022 年 5 月に Speedometer 3 が構想されてから、Chrome の Speedometer スコアは 72% 増加しました。これは、ユーザーのパフォーマンスが向上したと言い換えることができます。



ワークロードを最適化する

Speedometer のワークロードと Chrome で特に時間がかかっている関数を調べることで、最適化の対象を絞りこむことができ、それによって、Chrome のスコアが向上しています。たとえば、SpaceSplitString は頻繁に使われる関数で、"class='foo bar'"のようなスペース区切り文字列をリスト表現に変換します。この関数で、いくつかの不要な境界チェックを削除しました。重複するスタイルシートが存在することがわかった場合は、重複を排除し、1 つのスタイルシート インスタンスを参照するようにしています。また、メモリ割り当てを調整することで、パスや円弧の描画コストを削減する最適化を行いました。フォーム エディタの作成時には、フォーム要素を作成する際に不要な処理があったことがわかりました。querySelector でよく使われるセレクタを検出し、そのためのホットパスを作成しました。

以前にお知らせしたように、解析に特化した高速パスを使って innerHTML を最適化しましたが、この実装は WebKit にも採用されました。Speedometer 3 のワークロードには DOMParser を使っているものもあるため、同じ最適化を拡張することで、さらに 1% 向上させることができました。

また、Harfbuzz のメンテナンス担当者と協力し、Apple の Mac OS システム フォントで使われているような AAT フォントのレンダリング方法を最適化しました。テキストは、処理済みの Unicode 文字のストリームとして始まり、グリフのストリームに変換されてから、AAT フォントで定義されたステートマシンで実行されます。この最適化により、グリフが実際にステートマシンのルールの一部であるかどうかを高速に判断できるようになり、AAT によるテキスト処理のスピードアップにつながります。

注目すべき適切なコードを選ぶ

高いパフォーマンスを実現するために重要な戦略は、コードのティアリングです。これは、エンジンでさらに最適化できるコードを適切に選択することを指します。Intel は、V8 にプロファイルによるティアリングを提供しました。これは、過去のティアリングの決定を記憶する機能で、ある関数が過去に確実にティアリングされていれば、将来の実行時に積極的にティアリングするようにします。

ガベージ コレクションを改善する

Speedometer 3 で約 3% の向上につながったもう 1 つの変更領域がありました。それは、ガベージ コレクションの改善です。V8 のガベージ コレクタは、かなり以前からレンダラのアイドル時間を利用しています。これは、実際のアプリケーション コードに干渉しないようにするためです。最近の変更も、この考え方に則っています。つまり、レンダラは通常、非常に活発に動作していますが、可能な限り、そのアイドル時間にガベージ コレクションを行うように、既存のメカニズムを拡張します。具体的には、オブジェクトの再利用時に実行される DOM のファイナライズのコードもアイドル時間で実行されるようになっています。これまでこのような操作は、CPU リソースをめぐって通常のアプリケーション コードと競合していました。さらに V8 は、DOM 要素をラップするオブジェクト、つまり JavaScript フレームワークに公開されるすべてのオブジェクトで、はるかにコンパクトなレイアウトをサポートするようになっています。このコンパクトなレイアウトのおかげで、メモリ負荷が軽減され、ガベージ コレクションにかかる時間が短くなっています。


Reviewed by Eiji Kitamura - Developer Relations Team

Viewing all articles
Browse latest Browse all 2206

Trending Articles