Firefox 3.5 Beta 4のリリースを控え、再びそのパフォーマンスを検証する時期がやってきた。これまではJavaScriptの性能だけを見てきたが、今回からはロードタイムの計測なども含める。
使用するのは、Shiretoko Nightly（3.5b5pre, ID:20090424045037）である。バージョン番号は3.5b5preとなっているが、コードベースはFirefox 3.5 Beta 4と実質的に同じだ。なお、「3.5b5pre」の名称は暫定的なものにすぎないので、これをもってBeta 5がリリースされる可能性を云々することはできない。
比較対象として、これまで当ブログで紹介したShiretoko Nightlyの過去のバージョンのほか、Google Chrome（2.0.174.0, AppleWebKit/530.6）とSafari 4.0 Public Beta（AppleWebKit/528.16）を用いる。とくにGoogle Chrome（以下Chrome）は開発が進んでいるため、Shiretokoと比べるにはちょうどいいだろう。なお、すべてWindows Vista上で動作させている。
ロードタイム
ページの読み込み速度はWebブラウザにとって重要な指標だ。速ければそれだけストレスなくページを閲覧できるわけで、ユーザーにとっての関心も高いと思われる。そこで、WebWaitを利用してロードタイムを計測してみた。
以下に表を掲げるが、「初回」とあるのは、ディスクキャッシュをクリアした状態で、ブラウザの起動直後に1回だけ指定ページを読み込ませた場合を指す。初見のWebページを見るときのパフォーマンスを反映するはずとの読みだ。他方「平均」は、2〜4回目の読み込み時間を平均したもので、こちらはさまざまなキャッシュの扱い方が反映されるだろう。ちなみに、ロードの間隔は10秒に設定した。
まず、はてなのフロントページを指定したケースの結果を見てみよう。次のとおり、初回・平均ともにShiretokoが強い。Chromeよりも速いのは驚きだ。
| Shiretoko | Chrome 2.0 | Safari 4 | |
|---|---|---|---|
| 初回 | 4.18秒 | 4.55秒 | 4.73秒 |
| 平均 | 1.54秒 | 2.43秒 | 3.01秒 |
対象ページを変えて、Yahoo!ニュースで同様の計測を行った結果が、次の表だ。
| Shiretoko | Chrome 2.0 | Safari 4 | |
|---|---|---|---|
| 初回 | 4.97秒 | 5.11秒 | 7.09秒 |
| 平均 | 1.81秒 | 2.32秒 | 1.91秒 |
やはりShiretokoが強い。Safari 4は初回の読み込みが遅いものの、キャッシュが効いていると処理がかなり速い場合もあるようだ。
単純にレンダリング速度を比べれば、おそらくWebKitのほうがGeckoよりも優れているはず。また、描画速度に関してもChromeは定評があり、Shiretokoに遅れを取るとは思えない。そうすると、Speculative Parsing（投機的解釈）が威力を発揮しているのではないだろうか。現在のShiretokoは、外部スクリプトと外部スタイルシートの読み込みに関して、投機的解釈を実行する。対象となるファイルが複数ある場合、一つを読み込んでいる間も他の部分の読み込みや解釈を中断しない。ChromeやSafariのように処理を中断する無駄が生じないぶん、ロードタイムに好影響が出ていると考えられる。
スクロール
スタイルシートで背景画像を固定したWebページにおいても、スムーズにスクロールできるか。できるとすれば、CPU負荷は低く抑えられているか。『バグに関する話題 090302版』で扱ったように、その点をチェックできるテストケースがあるので、計測してみた。なお、「CPU負荷」は、タスクマネージャで示されたCPU使用率の最高値である。
| Shiretoko | Chrome 2.0 | Safari 4 | |
|---|---|---|---|
| 1回目 | 7138ms | 4319ms | 8583ms |
| 2回目 | 7187ms | 4312ms | 8782ms |
| 3回目 | 7182ms | 4299ms | 8732ms |
| CPU負荷 | 68％ | 65％ | 56％ |
Chromeのスムーズさが際立っている。Safari 4はこの処理が苦手なようだが、CPU負荷は他より低めだ。問題はShiretokoで、実はリグレッション（機能後退）が発生している。Firefox 3.1 Beta 3で計測してみると、4682msというChromeに近い成績を出し、CPU負荷も54％にとどまる。Beta 4の開発中にどこかで針が逆回転したわけだ。
JavaScriptベンチマーク
ここからはいつもどおりJavaScriptエンジンの性能をチェックする。『TraceMonkeyはトンネルを抜けた』を書いたとき以来だから、約三週間ぶりだ。
実は、Safari 4の再評価も今回のテストの重要な目的である。『Safari 4 Public Betaの実力や如何に』で一度ベンチマークにかけてはいるのだが、id:momdoさんが『主要ブラウザのJavascriptの実力を紐解いてみる』（血統の森+はてな）で公開されているデータを見ると、Safari 4はDromaeoベンチマークでChrome 2.0に近い数値を叩き出しており、筆者の測定とはかなり差がみられた。当時何らかの原因でSafari 4の動作が不完全なものになっていた可能性が十分考えられたため、本記事でベンチマークを実行する際は、その点をとくに注意した。
利用したベンチマークは、例によってSunSpider、V8、Dromaeoの三つ。最近の流行はFuturemarkの「Peacekeeper」だが、まだBeta版ということもあって見送った。
なお、Shiretokoの設定はjit.contentがtrue、jit.chromeがfalse（デフォルト）である。
Sunspider
最初に、過去のShiretokoと比較してみよう。4月初めのバージョンよりもわずかに数字がよくなっているが、期待していたほどではない。3月初めのバージョンはFirefox 3.1 Beta 3のベースとなったものだが、それと比べるとかなり進歩したように見えるけれども、Beta 3のリリース直前に入った修正で一時的に数値が落ち込んでいただけなので、あまり比較にならない。
| 20090424 | 20090401 | 20090303 | |
|---|---|---|---|
| Total | 2142.4ms +/- 0.6% | 2176.2ms +/- 0.7% | 2861.0ms +/- 0.8% |
| 3d | 315.8ms +/- 1.2% | 311.8ms +/- 0.7% | 482.8ms +/- 4.1% |
| access | 305.2ms +/- 1.8% | 313.0ms +/- 2.4% | 554.6ms +/- 0.8% |
| bitops | 66.8ms +/- 4.8% | 71.2ms +/- 2.3% | 76.8ms +/- 2.1% |
| controlflow | 99.2ms +/- 0.6% | 99.2ms +/- 1.0% | 98.8ms +/- 0.6% |
| crypto | 115.4ms +/- 2.5% | 115.8ms +/- 2.6% | 343.0ms +/- 1.8% |
| date | 311.0ms +/- 0.5% | 315.8ms +/- 3.5% | 287.2ms +/- 2.7% |
| math | 100.6ms +/- 4.7% | 98.4ms +/- 2.9% | 98.2ms +/- 0.6% |
| regexp | 151.4ms +/- 11.8% | 128.6ms +/- 5.9% | 148.4ms +/- 6.8% |
| string | 677.0ms +/- 1.6% | 722.4ms +/- 1.4% | 771.2ms +/- 0.8% |
次に、他のWebブラウザと比較してみると、かなり分が悪い。Chrome 2.0の数字は、一瞬別のPCでベンチマークを走らせたのかと思うほどだ。2月下旬の2.0.164.0は「1530.6ms +/- 2.2%」という成績だったので、そこからの伸びも素晴らしい。
| Shiretoko | Chrome 2.0 | Safari 4 | |
|---|---|---|---|
| Total | 2142.4ms +/- 0.6% | 1199.4ms +/- 2.2% | 1651.0ms +/- 0.2% |
| 3d | 315.8ms +/- 1.2% | 193.0ms +/- 6.2% | 322.6ms +/- 0.8% |
| access | 305.2ms +/- 1.8% | 102.2ms +/- 4.2% | 140.6ms +/- 0.5% |
| bitops | 66.8ms +/- 4.8% | 76.6ms +/- 2.7% | 67.4ms +/- 1.6% |
| controlflow | 99.2ms +/- 0.6% | 4.6ms +/- 14.8% | 7.0ms +/- 0.0% |
| crypto | 115.4ms +/- 2.5% | 83.6ms +/- 10.0% | 99.0ms +/- 1.3% |
| date | 311.0ms +/- 0.5% | 168.4ms +/- 4.0% | 175.2ms +/- 1.3% |
| math | 100.6ms +/- 4.7% | 115.0ms +/- 2.3% | 233.4ms +/- 0.8% |
| regexp | 151.4ms +/- 11.8% | 32.0ms +/- 39.2% | 51.6ms +/- 2.2% |
| string | 677.0ms +/- 1.6% | 424.0ms +/- 0.9% | 554.2ms +/- 0.5% |
また、Safari 4は、2月下旬のときと同じものを使っているのに、かなり数字が改善されている。ちなみに、当時は「1983.0ms +/- 1.3%」となっていた。ハードウェアか、ソフトウェアかは分からないが、何かが足を引っ張っていたのだ。今回の数値が本物である。正式版では当然さらに改良が加えられているだろうから、Firefox 3.5が逆転する見込みは極めて薄い。
最後に、TraceMonkeyを使わない場合（jit.contentもfalse）についても見ておこう。残念ながらこちらもあまり芳しい結果とは言えない。
| 20090424 | 20090401 | 20090303 | |
|---|---|---|---|
| Total | 5835.6ms +/- 0.9% | 5790.4ms +/- 0.8% | 5779.2ms +/- 0.4% |
V8
Shiretokoに関してV8ベンチマークの結果で注目すべきは、「Richards」の項目だけずば抜けて数値が上がっている点である。チューニング次第でこれだけ良くなるわけで、将来に期待がもてる内容だ。
| 20090424 | 20090401 | 20090303 | |
|---|---|---|---|
| Score | 175 | 138 | 141 |
| Richards | 773 | 131 | 142 |
| DeltaBlue | 45.0 | 55.1 | 66.3 |
| Crypto | 268 | 326 | 343 |
| RayTrace | 152 | 150 | 136 |
| EarleyBoyer | 186 | 159 | 185 |
| RegExp | 110 | 121 | 97.4 |
V8ベンチマークは、繰り返し述べているようにChromeのデモンストレーションのためにあるといっても過言ではないベンチマークだから、他と比べてChromeの圧勝になるのは当然の成り行きだ。2.0.164.0が1136だったことからすると、エンジン改良の効果も出ていて開発者たちも満足だろう。ちなみに、Safari 4は以前の計測でも809だったので変わらない。
| Shiretoko | Chrome 2.0 | Safari 4 | |
|---|---|---|---|
| Score | 175 | 1295 | 811 |
| Richards | 773 | 1361 | 1525 |
| DeltaBlue | 45.0 | 1250 | 1074 |
| Crypto | 268 | 1416 | 1466 |
| RayTrace | 152 | 1737 | 586 |
| EarleyBoyer | 186 | 2081 | 1738 |
| RegExp | 110 | 542 | 116 |
Dromaeo
ここまでの結果からすると、コードフリーズを遅らせる要因になったわりには、TraceMonkeyの開発成果が出ていないように見えた。しかし、その真価はDromaeoベンチマークで発揮されたのである。次の表をご覧いただきたい。
| 20090424 | 20090401 | 20090303 | |
|---|---|---|---|
| Total | 35.57runs/s ±3.17% | 29.85runs/s ±4.38% | 29.10runs/s ±3.77% |
わずか三週間で約20％の改善であり、これは大きい。ここまで差があれば、実環境でもBeta 3からの高速化を多少は体感できるのではないだろうか。また、Beta 3はSunSpiderで崩れていたが、今回そうしたバランスの悪さがなくなったのも嬉しいところ。やはりTraceMonkeyは低空飛行の時期を耐え抜き、着実にスコアを伸ばしていくフェーズに入ったのだ。
とはいえ、他のWebブラウザはさらにその先を行っている。たとえばSafari 4は再計測によって本来の実力が明らかになった（以前の測定時は10.10runs/s ±4.89%）。なおもChromeが最高の性能を誇ってはいるが、Safari 4はそれに近い数字を出している。また、ChromeはDromaeoに関して2月測定時（56.74runs/s ±6.22%）からほとんど変わっていない。Safariが正式版でエンジンを強化してくるであろうことからすると、トップランナーもうかうかしていられないところだ。ただ、これらとShiretokoとの差が縮まりつつあることは指摘しておきたい。
| Shiretoko | Chrome 2.0 | Safari 4 | |
|---|---|---|---|
| Total | 35.57runs/s ±3.17% | 57.52runs/s ±6.04% | 51.21runs/s ±2.31% |
総評など
Shiretokoのベンチマーク結果からみて、Firefox 3.5 Beta 4はスクロール性能を除き、Firefox史上最速である。セキュリティホールの件もあるが、純粋に性能だけをみても、Beta 3からただちに乗り換えるだけの理由が認められる。
しかし、強敵との厳しい競争に曝されていることも明らかだ。注目を集めやすいJavaScriptベンチマークを例に取ると、Firefox 3.5はChrome 2.0やSafari 4に勝てない。Firefox 3がリリースされた頃とは状況が違ってしまっている。
にもかかわらず、MozillaはFirefox 3.5のリリースに合わせて、「Fastest Firefox」キャンペーンを実施するという。もちろん、このキャンペーンはいわゆる「当社比」をアピールするものなのだろうが、現状を踏まえると、あまりうまい方法とは思えない。
「とくにスピードにフォーカスを当てる」という振る舞い自体が、「他社比」を誇示したがっているライバルたちを利するからだ。たしかにパフォーマンスの高さは新規ユーザーを惹きつけるうえで極めて重要な要素ではあるのだが、今Firefoxを売り込むなら、その点は柱の一つにとどめておき、豊富なアドオンや堅牢なセキュリティにも目を向けさせるべきだ。あるいは、表現力の豊かさを前面に押し出すのでもいいだろう。
これまでもFirefoxは高い総合力をアピールしてきたはずだ。それをもう一度繰り返せばいいだけで、何も難しいことはない。スピードを競ってライバルを圧倒できるならともかく、そういった状況にはないのだから、相手の土俵に乗っては損をするばかりだ。
