Mozilla Flux

意外な高速化を遂げたFirefox 10

Fx情報

Firefox 10の主な新機能といえば、アドオンの互換性確認の柔軟化やユーザーインターフェイスの改良、Web開発者向けツールの拡充などが中心で、処理の高速化はあまり意識されていない。Firefox 9の型推論（Type Inference）のように目立ったところがないからだろう。だが、ベンチマークを用いて性能を測ってみると、けっこう改善されていることがわかる。

実際の数字を見てみよう。比較対象は、以下のとおりWindows 7 SP1（64bit版）上で動作する32bit版のFirefox 9.0.1とFirefox 10.0。新規プロファイルを初期設定のまま利用し、アドオンはすべて無効化するが、プラグインはShockwave Flash 11.1（r102）だけを有効にした。使用したハードウエアは、CPUがIntel Core i5-2410M 2.30GHz、GPUがIntel HD Graphics 3000、メモリ容量が8.00GBで、Firefoxのハードウェア（HW）アクセラレーションも有効になっている。

• Firefox 9：Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
• Firefox 10：Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20100101 Firefox/10.0

メモリ使用量

以下の10のWebサイトをその記載順にあらかじめブックマークしておき、「タブですべて開く」でいっせいに読み込む。読み込みが完了したら、Firefoxのスタートページは閉じ、各タブをクリックしていって、Webページを実際に画面に表示させる。つまり最後に表示されるのはWikipedia（日本語版）になる。1分間そのまま放置した後、新しいタブを開き、about:memoryを呼びだしてExplicit Allocationsの値を見る。

• 日本マイクロソフト / アップル / 食べログ
• Amazon.co.jp / YouTube / NHKオンライン / 朝日新聞デジタル
• はてな / Yahoo! JAPAN / Wikipedia（日本語版）

「他のタブをすべて閉じる」でYahoo! JAPAN以外のWebページはすべて閉じる。1分間そのまま放置した後、再び新しいタブを開き、about:memoryを呼びだしてExplicit Allocationsの値を見る。結果は次のとおり。

	Firefox 9	Firefox 10
10サイト表示	106.65MB	102.40MB
単サイト表示	48.75MB	44.90MB

10サイト表示、単サイト表示ともにFirefox 10でメモリ使用量が削減されている。また、しばらく使ってみて感じるのだが、現に大量のメモリを使っている場合でもレスポンスが落ちにくい。具体的には、数バージョン前まで、Windowsタスクマネージャーに表示されるメモリ使用量が1GB付近になるとFirefox本体の反応が悪くなっていた。これに対しFirefox 10では、1.5GBくらいメモリを使用してもあまり差が生じない。

ページの読み込み

実環境によるテスト

WebWaitを用いて、指定したWebページを10秒間隔で5回読み込ませた。今回は、対象をYahoo! JAPANのトップページに変え、これだけに絞っている。それなりの容量のHTML文書で、CSSとJavaScriptに加えてFlashオブジェクトも含んでおり、ベンチマーク向きだと判断した。

	Firefox 9	Firefox 10
平均値	1.15秒	1.15秒
中央値	0.70秒	1.62秒

平均値は何と同値だった。Firefox 9/10ともに再読込の際に遅くなる回はなく、中央値はFirefox 9が勝っているので、これだけを見るとFirefox 10のほうが分が悪そうである。しかし、本当にそうなのか、次のテストで別の角度からチェックしてみよう。

Navigation Timingによるテスト

Internet Explorer 10 Test Driveに掲載されている多数のテストの1つ、Navigation Timingを利用してみる。Firefox 7からサポートされているNavigation Timingは、Webページをロードするのにかかった時間や状態などを返すAPIだ。上記テストは、このAPIを用いてWebブラウザの読み込み性能を計測するもので、ここでは差がわかりやすいように5MBのデータをダウンロードした場合の結果を示す。

	Firefox 9	Firefox 10
navigation	11247ms	10593ms
fetch	218ms	219ms

処理が完了するまでの時間はFirefox 10のほうが短いのに対し、ページの取得にかかる時間はほぼ同じ。つまりそれだけ処理性能が向上しているわけだ。

動的ページの処理

GUIMark 2から、Vector Charting TestとText Column Testをピックアップ。

Vector Charting Test

	Firefox 9	Firefox 10
fps	21.43	22.16

目視では違いを見いだせず、数値は今回も測定誤差だろう。

Text Column Test

	Firefox 9	Firefox 10
fps	53.1	51.85

前回Firefox 9を調べたときとは逆に、目視ではFirefox 10が若干遅い。Firefox 8の水準に戻った感じだ。

Canvasの描画

風と宇宙とプログラム「Canvasのベンチマークテストを作って速度を比較してみた」に掲載されていたCanvas Performance Benchmarkを用いて、Canvasの描画処理に関する性能を測定した。

	Firefox 9	Firefox 10
Total Score	2.89	3.02

実は一番驚いたのがこの結果で、当分横ばいだろうと思っていたらいきなりスコアが上がった。該当バグは見つけられなかったが、どこかでボトルネックが修正されたのかも。

HTML5/JavaScript総合

enchant.js

4Gamer.net「『enchant.js』でゲームはどれくらい動くのか？　HTML5でゲームベンチマークを取ってみよう」に掲載されていたシューティングゲームタイプのベンチマークを利用し、100秒間のフレームレートの合計値を測定した。

	Firefox 9	Firefox 10
Score	6352	7183

スコアが大きく伸びており、Firefox 7でマークしていた7000台を回復した。ただ、手放しでは喜べない。Firefox 8から発生している処理落ちは、なお残っている。それでもこのスコアになっているのは、通常動作の部分でパフォーマンスアップを達成しているからだ。目で見てはっきりわかるくらいにキビキビとしている。これで処理落ちの点がなくなれば完璧なのだが……。

Peacekeeper

FuturemarkのPeacekeeperは、リニューアルによって、PCだけでなくタブレットやスマートフォンも対象とするようになり、プラグイン不要のシンプルなベンチマークへと生まれ変わった。

	Firefox 9	Firefox 10
Points	1715	1972

総合ポイントを15％も積み増したのは立派な結果といえよう。詳細を眺めても個別のスコアでとくに落ち込んだ個所は見当たらず、Webブラウザ全体としての調整がうまくいっている。

JavaScript処理

代表的なJavaScriptベンチマークを利用して処理能力を測る。Firefox 9で大幅に強化された個所だけに、テスト前はそれほど差がないだろうと予想していた。

SunSpider

Chromium Blog「Updating JavaScript Benchmarks for Modern Browsers」で紹介されている、Google修正版（各テストを50回連続で行う）のSunSpider 0.9.1 JavaScript Benchmarkを使用した。数値が小さいほど高速である。

	Firefox 9	Firefox 10
Total	157.1ms +/- 1.0%	158.6ms +/- 2.2%

結果は誤差のレベル。もはやこのテストは多少のエンジンの改良には反応しなくなっている。

V8 Benchmark

V8 Benchmark Suite - version 6のスコアをチェック。

	Firefox 9	Firefox 10
Score	6735	6876

小幅ながらもFirefox 10のスコアが改善された。個別の項目では、RayTraceの値が3513から3740へ、EarleyBoyerの値が8299から8849へ、RegExpの値が1435から1612へとそれぞれ向上している。

Dromaeo

Dromaeo: JavaScript Performance Testingは、Mozillaが提供する重量級ベンチマークであり、JavaScriptエンジンなどにかなりの負荷をかけてその性能を測定してくれる。以下にRecommended Testsの最終結果を掲載する。詳細は比較表からどうぞ。

	Firefox 9	Firefox 10
Total	522.09runs/s ±1.98%	529.79runs/s ±1.91%

このテストでも総合スコアが上がっている。個別の項目だと3D Raytraceの改善が目立っており、V8 Benchmarkの結果とも合わせると、エンジンに補強が加えられたのは間違いなさそうだ。

Kraken

Kraken JavaScript BenchmarkはMozillaが提供するベンチマーク。従来のものと比べ、現実のWebアプリを処理した際の性能を反映した結果になるという。数値が小さいほど高速である。

	Firefox 9	Firefox 10
Total	3338.0ms +/- 0.6%	3089.7ms +/- 0.8%
ai	101.5ms +/- 1.7%	100.0ms +/- 1.7%
audio	1032.1ms +/- 1.3%	1061.5ms +/- 1.9%
imaging	1367.4ms +/- 0.5%	1170.9ms +/- 0.6%
json	187.4ms +/- 5.8%	190.0ms +/- 1.5%
stanford	649.6ms +/- 2.8%	567.3ms +/- 1.3%

imagingとstanfordの項目で数値が改善されており、総合スコアでもFirefox 10が勝利を収めた。JITコンパイラの着実な進化を窺わせる。バージョンアップのたびに少しずつスコアが下がり続けるというジンクスも、これで払拭されたとみてよさそうだ。

総合評価

前回、Firefox 9は高速だが処理性能にムラがあるので、Firefox 10での調整に期待するという趣旨のことを書いた。その期待に見事に応えるバージョンアップが行われ、パフォーマンスはおおむね全般的に良くなった。しかも、消費メモリの抑制が進んでいる。法人向け延長サポート版（ESR）の基盤となるにふさわしい仕上がりといえよう。

Firefox 9からのアップデートをためらう理由はない。また、Firefox 3.6.xのサポート終了が具体的な話となってきた（2012年4月24日とアナウンスされている）現在、Firefox 10へのメジャーアップデートも十分に魅力的な選択肢だと思う。使い慣れたアドオンのいくつかを諦めてでも、乗り換えるだけの価値はある。

ツイートする

Permalink | コメント(0) | トラックバック(0) | 00:27

型推論の実装は高速リリースサイクルの試金石だった

Fx解説

Firefox 9の目玉機能であるJavaScriptの型推論（Type Inference：TI）。この機能をリリース版に投入できたことによって、ようやく本当に高速リリースサイクルを維持するめどが立ったといっても過言ではない。それくらい、TIの実装は開発プロセスにおいて重要なチャレンジだった。

話は2011年8月上旬に遡る。同年6月にJavaScriptエンジンのモジュールオーナーを継いだMozillaのDavid Mandelin氏が、mozilla.dev.planningニュースグループに1本のスレッドを立てた。『Shipping Type Inference and Other "Irreversible" Changes』と題されたそのスレッドにおいて、Mandelin氏は、TIの導入に当たって開発プロセス上の課題があると指摘した。

TIはJavaScriptエンジン全体を通じて多数の個所を変更するため、問題が生じても単純に設定をオフにするだけでは回避できない。かといって、変更点を逐一撤回する（バックアウト）となると、それ自体のコストが大きいだけでなく、TIを前提とした別の修正が加えられていた場合にその個所にも手を入れねばならず、あまり現実的ではないというのだ。

Mandelin氏は言及していないが、ここで想定されているのは、Nightly・Aurora・Betaというチャンネルを経ても問題を修正しきれないケースだ。開発用のリポジトリ（コードの集合体）でテストを行うのは当然として、Nightlyチャンネルまで目一杯使えば最長18週間の余裕があるものの、その期間内にTIがリリース水準の品質にまで到達できる保証はない。

設定をオフにすることや、バックアウトといった一般的な対処法では扱いが困難なほどの大きな機能の追加。Mandelin氏が「不可逆的変更」と呼ぶこうした事態は、今後も起きることが確実だ。TIの実装は高速リリースサイクルの今後を占う試金石といえた。

Mandelin氏は、この課題に対し、予備のリポジトリを用意してそこにTIを投入するという解決策を提案した。Nightlyチャンネルのメインリポジトリ（mozilla-central）に加えられた修正を毎日自動的に予備のリポジトリにコピーし、Aurora・Betaチャンネルでもやはり予備のリポジトリを設けて同様の措置を続ける。そして、TI版の動作が安定したと判断できた時点で予備とメインを切り替えるが、問題が見つかれば切り替えを元に戻す。これをユーザー視点から見ると、たとえばFirefox Auroraを使っているとあるときTI版が提供されるが、クラッシュが多発するなど問題が生じたときは再び非TI版が提供されるようになるわけだ。もちろん、この案でも「動作が安定している」ことを18週間のうちに確認しきれるかどうか疑問は残るが、リリース時期への影響は最小限に抑えられる。

上記の提案を巡って熱心な議論が交わされ、最終的に次の3つの案がテーブルの上に載った。(1)TIをmozilla-centralに投入し、必要なら正式版のリリースを6週間延期する。(2)TIをmozilla-centralに投入し、ダメだと判断したらJavaScript関係の変更を撤回して、付随するGecko（レンダリングエンジン）の変更も元に戻し、JavaScript関係で必須の修正のみ再投入する。(3)TIをmozilla-centralに投入し、非TI版のリポジトリを予備として維持する。ご覧のとおり(3)案が当初の提案を反映したもので、Mandelin氏は同案を推した。意見を若干変えたのは、最初からTI版をメインにしたほうがユーザーからのフィードバックを多く得られるからだろう。

「さて、メールスレッドでどうやって決めたらいい？」Mandelin氏は結論を出す方法を尋ねた。するとMozillaの重鎮Mike Shaver氏（当時）は、自身(2)案を推しながらも、以下のとおり答えた。

You're the module owner, and you're on the hook for the results, so you make the call. Just let people know what it is; you've certainly gone out of your way to get feedback and advice.

君がモジュールオーナーで、君が結果に責任を負う立場だ。だから決断するのも君だ。結論だけはみんなに教えてくれ。わざわざ意見やアドバイスを求めたのは確かなんだからね。

Mozillaの製品開発が開発者主導であることをよく表している。そして、モジュールオーナーの権限がいかに大きいかも。議論にはリリースマネージャのChristian Legnitto氏やDirector of Firefox EngineeringのJohnathan Nightingale氏も参加していた。彼らでさえもモジュールオーナーの決定はひっくり返せないのだ。

Mandelin氏は、自ら最良と信じる(3)案を実行することに決めた。結果はみなさんご承知のとおり。TIは無事ユーザーの手に届き、高速リリースサイクルの中でもFirefoxは大きな機能を追加できることが証明された。Mandelin氏の手腕に拍手を送りたい。

最後に、JavaScriptエンジンの前モジュールオーナー、「JavaScriptの父」ことBrendan Eich氏が、Mandelin氏をどう評しているのか紹介しておこう。Mandelin氏が重い地位を譲るにふさわしい人物であることを示す一言だ。

Dave is even-tempered, super-smart, and a true empirical/skeptical scientist in the spirit of my hero, Richard Feynman.

Daveは、落ち着いていて、とびきり聡明で、私が憧れるリチャード・ファインマンのような経験主義的・批判的精神を持ち合わせた真の科学者だ。

ツイートする

Permalink | コメント(0) | トラックバック(0) | 22:01

Firefox 12・13でシステム要件の見直しへ

Fx新着

Firefox 12あるいは13でシステム要件が見直され、Windows版ではWindows XP Service Pack 2以降が対象になりそうだ。また、Mac版でもMac OS X v10.6（Snow Leopard）以降を対象とする方向で話が進んでいる。Firefox 9のシステム要件と比較すると、Windows 2000、XP無印、XP SP1そしてMac OS X v10.5（Leopard）が対象から外れることになる。

Windows版はFirefox 12からの見通し

先に要件が変更されるのはWindows版で、Firefox 12（2012年4月24日ころリリース予定）から実施される可能性が高い。実はこの話題、当ブログで2年半以上も前に『Firefox.nextのサポート対象はXP SP2以降となる見とおし』という記事として取り上げたことがある。その後、Firefox 4でも要件が維持される一方、XP SP2のサポート提供が終了した。ただ、今回の変更では、XP SP1以前ではFirefoxの起動すらできなくなる点に注意が必要だ。

Windows版のシステム要件が変わるのは、ビルド環境がMicrosoft Visual C++ 2010に移行するためである（Bug 563318）。Microsoft提供の文書によると、Visual C++ 2010 C/C++のランタイムはWindows XP SP2で導入されたAPIに依拠しているため、このランタイムを使用するプログラムはXP SP1以前のOSでは動作しない。

それでも、2011年12月下旬、MozillaでPlatform Engineering部門のDirectorを務めるJP Rosevear氏が、Firefox 12からビルド環境をVisual C++ 2010に移行してはどうかと提案しているところをみると、メリットのほうが大きいとの判断があるのだろう。そのメリットの1つはパフォーマンスアップである。他にも64bit環境にインストールすることで4GBの仮想メモリにアクセスできるようになるとか、従来のVisual C++ 2005に合わせた修正が不要になるといった消極的なメリットもある。

上記の提案の裏で、準備は着々と進行中だ。2011年11月下旬の時点で、既に基本的なテストは終えた。また、同年12月上旬には、アップデート機能を利用する際、OSのサービスパックのバージョンをチェックする仕組みがFirefox 9に投入された（Bug 668436）。あとはコンセンサスが形成されるのを待つばかりだ。

影響を受けるユーザーの数はさほど多くないとみられるが、該当する場合、ユーザー側の対策については悩ましい問題がある。Firefox 12でシステム要件の変更が実施されると、Firefox 11に対するアップデートが提供されなくなるわけだが、企業ユーザー向けの延長サポートリリース版（ESR版）を使用するにしても、現在のところ最初のESR版はFirefox 10がベースになる見込みだ。つまり、Firefox 11が登場した時点（2012年3月13日ころリリース予定）で、ESR版に切り替えるのか、それともいったんアップデートした後でダウングレードするのかを決めねばならない。検討の猶予はあまり残されていない。

Mac版はFirefox 13からの見通し

Mac版のシステム要件の見直しは、mozilla.dev.planning『Discussing Mac OS X 10.5 Support Plans』で議論されている。MozillaのJosh Aas氏は、Firefox 13（2012年6月5日ころリリース予定）でMac OS X v10.5（Leopard）をサポートから外すことを提案している。

その理由は、Mac OS Xユーザーのうち10.5ユーザーの占める割合が2011年11月8日現在24％で、毎月1〜2％ずつ減少していること、Appleが比較的迅速に新バージョンをリリースしている上、各バージョンで変更された部分も大きいのでサポートコストを抑える必要があること、10.5ユーザーは既にWebGLなどFirefoxの機能の一部を使えない状態にあること、そしてAppleが10.5のサポートを停止したことの4点だ。

Aas氏の提案に対しては当然反対意見も出ているが、説得力のある根拠が示されない限りこの提案が通ると思われる。かつて当ブログで『Firefox.nextはMac OS X 10.4もサポートから外す方針』という記事を書いた。Firefox 3.5の次のバージョンでMac OS X 10.4をサポートから外すという話題で、このときもAas氏の提案が発端になっていた。結局10.4をサポートしなくなったのはFirefox 4からであり、3.6ではなかったものの、高速リリースサイクルを採用して新機能をスピーディーに提供する方向にシフトしたMozillaは、どういう選択をするだろう。最新版のサポートコストは減らして、そこから生じる問題はESR版で解決しようとするのではないか。

影響を受けるユーザーの対策については、Windows版と同様の問題がある。ESR版との差がより開く分、Firefox 11がリリースされたときの判断はより難しいものとなろう。

ツイートする

Permalink | コメント(0) | トラックバック(0) | 17:09

サイドバーの項目を若干見直し

その他

サイドバーの項目を少し変更しました。最新タイトルと注目エントリーを目立つところに移動させるとともに、筆者のはてなブックマークも表示するようにしました。

最新タイトルと注目エントリーは、検索サイト経由で訪れた方にとって、他の記事に目を向けていただくきっかけになると思います。また、筆者のブックマークは、Mozilla関連の話題が大多数を占めていますので、新たにこれをパーツに加えることで、繰り返し当ブログにお越しくださる方にも新しい情報を提供できるのではないかと考えました。

なお、上記ブックマーク（『Rockridge のブックマーク』）は、「全件何かしらのコメントをつける。「あとで読む」は入れない。」という方針を採用しており、ミニブログ的な位置付けです。よろしければご一読ください。

ツイートする

Permalink | コメント(0) | トラックバック(0) | 08:37

Firefox 9：型推論の効果やいかに

Fx情報

Firefox 9の注目点は、何といってもJavaScriptの実行速度の向上だ。Mozilla Developer Streetで紹介されているように、型推論（Type Inference：TI）と呼ばれる技術が実装され、JaegerMonkey（JM）が従来よりも高速なコードを生成できるようになった。今後はこのJM＋TIがJITコンパイラの中核を担い、TraceMonkeyはその役割を終えることになる。

はたして型推論の効果は出ているのか。ベンチマークをとってみよう。比較対象は、以下のとおりWindows 7 SP1（64bit版）上で動作する32bit版のFirefox 8.0.1とFirefox 9.0（Beta 6）。新規プロファイルを初期設定のまま利用し、アドオンはすべて無効化するが、プラグインはShockwave Flash 11.1（r102）だけを有効にした。なお、初期設定でハードウェア（HW）アクセラレーションが有効になっている。

• Firefox 8：Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0.1) Gecko/20100101 Firefox/8.0.1
• Firefox 9：Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20100101 Firefox/9.0

メモリ使用量

まずはメモリ使用量の計測から。以下のWebサイトをその記載順にあらかじめブックマークしておき、この10サイトを「タブですべて開く」でいっせいに読み込む。読み込みが完了したら、各タブをクリックして、Webページを実際に画面に表示させる。つまり最後に表示されるのはWikipedia（日本語版）になる。1分間そのまま放置した後、about:memoryを呼びだしてExplicit Allocationsの値を見る。

• 日本マイクロソフト / アップル / 食べログ
• Amazon.co.jp / YouTube / NHKオンライン / asahi.com
• はてな / Yahoo! JAPAN / Wikipedia（日本語版）

次に、「他のタブをすべて閉じる」でYahoo! JAPAN以外のWebページはすべて閉じる。1分間そのまま放置した後、再びabout:memoryを呼びだしてExplicit Allocationsの値を見る。結果は次のとおり。

	Firefox 8	Firefox 9
10サイト表示	106.77MB	103.25MB
単サイト表示	45.37MB	45.08MB

単サイト表示では差が出ないが、10サイト表示だとFirefox 9のほうがメモリ消費量は少ない。高速化がメモリ消費量の増大につながるケースもあるが、今回その心配はなさそうだ。

ページの読み込み

WebWaitを用いて、指定したWebページを10秒間隔で5回読み込ませた。Yahoo!ニュースとasahi.comを対象にしており、秒数が少ないほど高速だ。

Yahoo!ニュース

	Firefox 8	Firefox 9
平均値	0.83秒	1.16秒
中央値	0.48秒	2.26秒

残念ながらFirefox 9のパフォーマンスが低下している。再読込の際になぜか遅くなる回があり、それが足を引っ張っているのだ。前回のテストでFirefox 8はスムーズな読み込みを行えており、今回もそれが変わっていないことからすると、Firefox 9の処理のどこかに問題があるのかもしれない。

asahi.com

	Firefox 8	Firefox 9
平均値	2.39秒	1.75秒
中央値	1.98秒	1.25秒

こちらはFirefox 9が平均値、中央値ともに明らかに勝っている。読み込みが極端に遅くなる回がなかったためである。つまり性能的にはFirefox 9が上なのに、不得意なページに当たるとパフォーマンスが落ちるようなのだ。実にもったいない。初回ではなく2回目以降で問題が発生していることから、キャッシュの処理が影響していることも考えられる。

動的ページの処理

GUIMark 2から、Vector Charting TestとText Column Testをピックアップ。今回からテストを2つに減らした。

Vector Charting Test

	Firefox 8	Firefox 9
fps	22.08	21.96

今回もまた、測定誤差のレベルでしか違いがみられなかった。

Text Column Test

	Firefox 8	Firefox 9
fps	52.63	53.69

これも誤差かもしれないが、目視ではFirefox 9が心もち速くなったように感じた。

Canvasの描画

風と宇宙とプログラム「Canvasのベンチマークテストを作って速度を比較してみた」に掲載されていたCanvas Performance Benchmarkを用いて、Canvasの描画処理に関する性能を測定した。

	Firefox 8	Firefox 9
Total Score	2.90	2.90

前回の予想どおり、性能に変化はない。

HTML5/JavaScript総合

enchant.js

4Gamer.net「『enchant.js』でゲームはどれくらい動くのか？　HTML5でゲームベンチマークを取ってみよう」に掲載されていたシューティングゲームタイプのベンチマークを利用し、100秒間のフレームレートの合計値を測定した。

	Firefox 8	Firefox 9
Score	6282	6411

前回最大の問題として指摘した個所だが、Firefox 9でもやはり処理落ちが発生する。スコアはFirefox 9がFirefox 8を上回っているものの、Firefox 7が7000台をマークしていたことを思えば、満足のいく結果ではない。JavaScriptエンジンの強化によっていわば力業でスコアを引き上げただけで、根本的な解決にはなっていない。

Peacekeeper

総合テストとして、新たにFuturemarkのPeacekeeperを加える。以前から存在していたが、リニューアルによって、PCだけでなくタブレットやスマートフォンも対象とするようになり、プラグイン不要のシンプルなベンチマークへと生まれ変わった。

	Firefox 8	Firefox 9
Points	1788	1717

総合ポイントではFirefox 9が劣る結果に。詳細をみてもスコアの浮き沈みがけっこうあり、Webブラウザ全体をバランスよく調整することの難しさが浮き彫りとなった。

JavaScript処理

代表的なJavaScriptベンチマークを利用して処理能力を測る。JM＋TIの真価が問われる部門だ。

SunSpider

Chromium Blog「Updating JavaScript Benchmarks for Modern Browsers」で紹介されている、Google修正版（各テストを50回連続で行う）のSunSpider 0.9.1 JavaScript Benchmarkを使用した。数値が小さいほど高速である。

	Firefox 8	Firefox 9
Total	186.7ms +/- 1.9%	160.4ms +/- 3.2%

さっそく型推論の効果が出たようだ。JavaScriptエンジンの高速化が進み、SunSpiderでは差がつきにくくなっている中、着実にスコアを伸ばしている。

V8 Benchmark

次に、V8 Benchmark Suite - version 6のスコアをチェック。

	Firefox 8	Firefox 9
Score	5002	6746

これは文句なしにFirefox 9の勝利だ。個別の項目では、DeltaBlueの値が5296から10493へ、Cryptoの値が6702から15152へと向上しているのが目につく。

Dromaeo

Dromaeo: JavaScript Performance Testingは、Mozillaが提供する重量級ベンチマークであり、JavaScriptエンジンなどにかなりの負荷をかけてその性能を測定してくれる。以下にRecommended Testsの最終結果を掲載する。詳細は比較表からどうぞ。

	Firefox 8	Firefox 9
Total	468.79runs/s ±1.51%	503.58runs/s ±1.92%

Firefox 4以降あまり変化がなかったこのテストでも、JM＋TIの効果が出ているのは明白だ。上記の詳細をみてもらうと分かるが、一部のテストでスコアが大きく増加しており、これが総合値を引っ張り上げている。

Kraken

Kraken JavaScript BenchmarkはMozillaが提供するベンチマーク。従来のものと比べ、現実のWebアプリを処理した際の性能を反映した結果になるという。数値が小さいほど高速である。

	Firefox 8	Firefox 9
Total	4604.0ms +/- 2.1%	3346.7ms +/- 0.9%
ai	751.9ms +/- 0.9%	99.6ms +/- 1.3%
audio	1570.9ms +/- 6.5%	1048.0ms +/- 1.7%
imaging	1388.2ms +/- 1.4%	1362.3ms +/- 0.4%
json	169.7ms +/- 1.8%	190.9ms +/- 7.6%
stanford	723.3ms +/- 0.6%	645.9ms +/- 2.5%

Firefox 4以降、少しずつスコアが下がり続けていたこのベンチマークで、Firefox 9は一転して好成績を収めた。一部のテストで劇的な改善を遂げていることから、JM＋TIの組み合わせが上手くハマったときは相当な効果が上がるらしい。

総合評価

Firefox 9は、メモリ消費量を犠牲にすることなくJavaScriptの処理性能を改善しており、この点はユーザーにとってのメリットが大きい。日常的な使用の範囲では、Webページの処理が速くなることで、これまでよりも快適なブラウジングが可能になるだろう。

他方、Webアプリ系のベンチマークでは若干の問題が見つかっており、あらゆる場面で高速化を達成できるようにバランスをとるのは難しい様子である。ただ、6週間で次のバージョンが出るので修正されるのも早い。Firefox 10での調整に期待したいところだ。

ツイートする

Permalink | コメント(0) | トラックバック(0) | 00:22