当ブログでは、延長サポート版(ESR)のメジャーアップデートが行われる時期をFirefoxの開発の区切りとみて、Web上で実行可能なベンチマークの測定結果を公開している。Firefox 38のリリースを目前に控え、今回はこれを中心に、Firefox 2431およびChrome 42と比較してみたい。
検証を行った具体的なバージョンを挙げると、32bit版のFirefox 31.6.0(ビルドID:20150325203137)およびFirefox 38.0 RC1(ビルドID:20150503173159)、それに64bit版のChrome 42(バージョン:42.0.2311.135m)である。Googleが一般ユーザー向けに64bit版Chromeを提供し、そこで性能の向上を謳っている以上、これに目をつぶって32bit版で揃えてもフェアではないだろうと判断した。
動作環境についてだが、OSはWindows 8.1 Update 1(64bit版)で、使用したハードウエアは、CPUがIntel Core i7 4800MQ 2.70GHz、GPUがIntel HD Graphics 4600(ドライバのバージョン:10.18.10.3338)、メモリ容量が16.0GBである。テストの際は、新規プロファイルを(フォントをメイリオに変更する以外は)初期設定のまま利用し、アドオンをすべて無効化し、プラグインもShockwave Flash 17.0 r0以外を無効化した。これはChromeでも同様だが、他方、Firefox 38では、自動的にインストール/有効化されるOpenH264 Video Codec 1.4とPrimetime Content Decryption Module 9を有効のままにしている。なお、各ベンチマークの実行後はFirefox(Chrome)を終了させて、メモリ上に前のベンチマークが残らないように配慮した。
また、前回の記事のコメント欄でのご指摘を踏まえ、Turbo Boost機能を無効化してからベンチマークを実行した(参照:Surface Pro 3 の Turbo Boost を無効化する)。Turbo Boostが有効の場合、定格の動作周波数よりどの程度高速になるか決まっていないため、新バージョンのブラウザでベンチマークの数値が改善されたとしても、単にCPUの働きによるものだったという可能性が残る。これを無効にすることで、測定結果の正確性が高まるはずだ。
最後に、対象となるベンチマークは、前回の記事で用いたものを一部削って、新しいものを導入している。
ページの読み込み速度およびメモリ使用量
10のWebサイトを同時に開いて、読み込み中であることを示すアイコン(throbber)が消えるまでの時間を手動で計測した(秒数の小数点以下は切上げ)。同時に、10サイトを表示させた場合と、単サイトを表示した場合のメモリ使用量もチェックした。
具体的な手順は、次のとおり。以下の10サイトをその記載順にフォルダ内にブックマークしたバックアップファイル(FirefoxではJSON形式、ChromeではHTML形式)をインポートし、「タブですべて開く」(Chromeでは「すべてのブックマークを開く」)で10サイトをいっせいに読み込む。throbberが消えるまでの時間を計測し、完了したらFirefox(Chrome)のホームページは閉じ、各タブをクリックしてWebページを実際に画面に表示させる。つまり最後に表示されるのはWikipedia(日本語版)になる。
- 日本マイクロソフト / Apple / 食べログ
- Amazon.co.jp / YouTube / NHKオンライン / 朝日新聞デジタル
- はてな / Yahoo! JAPAN / Wikipedia(日本語版)
1分間そのまま放置した後、新しいタブを開いてabout:memoryを呼びだす。Firefoxでは"Show memory reports"のMeasureボタンをクリックし、Main Processのresidentの値を見る。もっとも、これだけではChromeとの比較ができないため、同時にChromeのabout:memoryからもFirefoxのプロセスのPrivate Memoryの値をチェックする。
そして、「他のタブをすべて閉じる」でYahoo! JAPAN以外のWebページはすべて閉じる。1分間そのまま放置した後、再び新しいタブを開き、about:memoryを呼びだしてMain Processのresidentの値を見る(ChromeではPrivate Memoryの値をチェックする)。Firefox(Chrome)をいったん終了させ、再起動後に上記10サイトを同じ手順で開いて、throbberが消えるまでの時間を計測する。一連の手順を実行した結果がこれだ。
Firefox 31 | Firefox 38 | Chrome 42 | |
---|---|---|---|
読込時間(1回目) | 25 秒 | 16 秒 | 14 秒 |
読込時間(2回目) | 15 秒 | 15 秒 | 7 秒 |
Firefox 31 | Firefox 38 | Chrome 42 | |
---|---|---|---|
使用メモリ(10) | 378.71 MB(355,464 KB) | 408.78 MB(383,952 KB) | 727,012 KB |
使用メモリ(1) | 268.30 MB(237,336 KB) | 305.85 MB(293,008 KB) | 206,904 KB |
読み込み速度についてみると、Firefox 38において1回目の読み込みに要する時間が短縮されている。これは、新しいHTTPキャッシュ(cache v2)を導入したことによるものだろう。他方、2回目の読み込みに要する時間は変わらないが、改善の余地があることはChromeとの比較から明らかだ。
メモリ使用量は、Firefox 38において増加傾向にある。世代別ガベージコレクション(Generational GC)も導入済みだが、メモリの解放には限界があるのかもしれない。これに対し、Chromeは派手な結果が出ている。Firefoxの数値と比較するときは、カッコ内の数字を参照してもらいたいのだが、10タブを開いたときのChromeのメモリ使用量は、Firefoxの倍まではいかないにせよ、かなり多い。ところが、タブを閉じていくと一転してメモリ使用量が激減するのだから面白い。ひょっとすると、ディスクキャッシュを用いた再読み込みの速度に自信があるので、メモリキャッシュは少なくてもよいと割り切っているのだろうか。
レイアウトおよび描画処理
HTML5 Canvas
CanvasMark 2013 version 1.1は、HTML5ゲームでよく使用される処理(ビットマップ、Canvas描画、αブレンディングなど)に対するレンダリング・パフォーマンスをテストする。
Firefox 31 | Firefox 38 | Chrome 42 | |
---|---|---|---|
CanvasMark Score | 8459 | 9716 | 10268 |
Firefox 38が約15%もスコアを伸ばしているのは立派なものだ。Chromeには届かないが、背中は見えてきている。
次に、Canvas Cycleは、HTML5 Canvas上に8bitのカラーパレットを用いたアニメーションを表示し、サウンドも鳴らすデモだ(解説)。オプションを表示させると秒間フレーム数(FPS)が出るので、"Jungle Waterfall - Morning"を初期設定のまま走らせてみた。
Firefox 31 | Firefox 38 | Chrome 42 | |
---|---|---|---|
秒間フレーム数 | 86 - 89 fps | 98 - 102 fps | 119 - 120 fps |
Firefox 38で性能の向上がみられるが、Chromeはその先を行っている。
CSSレイアウト
Internet Explorer 11 Test DriveからMaze Solverをピックアップし、迷路のサイズを30×30に設定してテストを実行した。このテストは、WebブラウザがCSS 2.1およびCSS 3ベースのレイアウト構築を処理する性能に焦点を当てており、数値が小さいほど高速である。
Firefox 31 | Firefox 38 | Chrome 42 | |
---|---|---|---|
Browser Score | 13.0 秒 | 15.0 秒 | 5.5 秒 |
Firefox 38の成績が振るわない。Chromeとの差も大きく、改善が望まれる。
WebGL
Internet Explorer 11 Test DriveからFishGLをピックアップし、水槽内の魚の数を150匹に設定してテストを実行した。 このテストは、主にWebGLに関する処理性能を測定するものだ。
Firefox 31 | Firefox 38 | Chrome 42 | |
---|---|---|---|
秒間フレーム数 | 41 - 45 fps | 46 - 50 fps | 35 - 44 fps |
Firefox 38が最も高いFPSを記録した。他方、ChromeではFPSが安定せず、Firefox 31のそれを下回ってしまった。
次に、Unity WebGL Benchmarksでの結果を見てみよう。このベンチマークは、2014年10月に公開された新しいもので、Unity Blogの記事によれば、さまざまな場面で、Unityの開発したエンジンが一定時間内にどの程度のタスク処理ができるのかをテストするという。
Firefox 31 | Firefox 38 | Chrome 42 | |
---|---|---|---|
Overall Score | N/A | 48573 | 38287 |
Firefox 31は、一部のテストで描画が正しく行われず、異常な数値が出るため結果を掲載していない。この現象のせいで、Firefox 38がどの程度の性能アップを果たしたのかもわからずじまいだ。とはいえ、Firefox 38が叩き出したスコアは、Chromeに大差をつけている。最近のFirefoxがWebGLに強いのは間違いなさそうだ。
JavaScript/DOM処理
JavaScript
Octane JavaScript Benchmark は、V8 Benchmark Suiteの後継となるベンチマークで、モダンなWebアプリを実行した場合の性能を反映した結果になるという(FAQ)。Octane 2.0では、スループットに加えてレイテンシも重視するようになった。言い換えれば、Webアプリのピーク性能だけでなく、動作のスムーズさも評価の対象となったわけだ。
Firefox 31 | Firefox 38 | Chrome 42 | |
---|---|---|---|
Octane Score | 18318 | 23124 | 24547 |
Richards | 25019 | 27896 | 25718 |
Deltablue | 22077 | 33852 | 44901 |
Crypto | 20772 | 23509 | 23267 |
Raytrace | 21312 | 45361 | 50393 |
EarleyBoyer | 24217 | 32689 | 34848 |
Regexp | 1969 | 2300 | 3917 |
Splay | 14318 | 15728 | 13430 |
SplayLatency | 9437 | 19901 | 22311 |
NavierStokes | 22002 | 27251 | 22445 |
pdf.js | 14423 | 13952 | 18080 |
Mandreel | 19200 | 22615 | 23194 |
MandreelLatency | 25435 | 26238 | 18532 |
GB Emulator | 34141 | 50996 | 56205 |
CodeLoad | 15287 | 15749 | 15062 |
Box2DWeb | 26515 | 36363 | 32402 |
zlib | 44166 | 46690 | 50087 |
Typescript | 19729 | 21205 | 32150 |
意外なことにFirefox 38が約26%もスコアを伸ばし、Chrome 42に肉薄している。世代別GCの導入がレイテンシ重視というOctane 2.0のコンセプトにマッチしたからだろうか。V8 Benchmark Suiteの時代から、FirefoxはChromeに大差をつけられてきただけに、Google製のベンチマークでこの結果が出たことは大きい。ちなみに、Firefox 29から35までの間に、Octane 2.0のスコアが約40%向上したという話もある。
次に、JetStream 1.0.1を採り上げる。JetStreamはWebKitチームが提供するベンチマーク・スイートで、スループットとレイテンシを計測する点はOctane 2.0とコンセプトが共通している。実際、SunSpider 1.0.2のほか、Octane 2.0からも一部のベンチマークを取り入れているという(参照:Introducing the JetStream benchmark suite)。
Firefox 31 | Firefox 38 | Chrome 42 | |
---|---|---|---|
Score | 136.70 ± 1.3351 | 148.21 ± 5.0053 | 156.65 ± 2.9681 |
Chromeには及ばないものの、Firefox 38のJavaScriptエンジンが大きく改良されていることは間違いない。
JavaScript+DOM
Speedometer 1.0は、WebKitチームが提供するベンチマークで、DOMオブジェクトの操作に焦点を当て、Webアプリの応答性を測定する。jQueryなど6つのポピュラーなJavaScriptフレームワークを採用し、ユーザーの行動をシミュレートするという。
Firefox 31 | Firefox 38 | Chrome 42 | |
---|---|---|---|
Runs / Minute | 52.28 ± 0.50 | 57.1 ± 0.85 | 78.44 ± 0.70 |
Firefox 38はWebアプリの応答性という点でも進歩している。もっとも、Chromeと比較すると見劣りする面があり、まだまだ改善が必要だ。
asm.js
Emscriptenプロジェクトの一環として公開されているベンチマーク・スイートEmbenchen v0.0.2を利用して、asm.jsの処理性能を見る(参照:asm.js performance improvements in the latest version of Firefox make games fly! ?)。このベンチマーク・スイートは、マイクロベンチマークとマクロベンチマークから構成されるが、性能の指標としては実環境に近い後者が重要となるので、本記事でもマクロベンチマークの結果を掲載する。なお、数値が小さいほど高速である。
Firefox 31 | Firefox 38 | Chrome 42 | |
---|---|---|---|
box2d | 12,056 ミリ秒 | 11,628 ミリ秒 | 11,578 ミリ秒 |
bullet | 12,847 ミリ秒 | 12,529 ミリ秒 | 15,829 ミリ秒 |
lua_binarytrees | 7,266 ミリ秒 | 6,985 ミリ秒 | 10,876 ミリ秒 |
zlib | 11,945 ミリ秒 | 12,606 ミリ秒 | 11,650 ミリ秒 |
OdinMonkeyを搭載したFirefoxの圧勝、というわけにはいかなった。Chromeもさほど規模の大きくないasm.jsコードであれば、ある程度高速な処理が可能であるらしい。
次に、同じくEmscriptenプロジェクトの一環として公開されているベンチマーク・スイートMASSIVE v1.1を走らせてみよう。このベンチマークは、大規模なasm.jsコードに特化しており、Poppler、SQLite、LuaとBox2Dのコードをベースに、スループットだけでなく、読み込み時間や読み込み中の応答性、パフォーマンスの一貫性なども計測対象とするものだ。
Firefox 31 | Firefox 38 | Chrome 42 | |
---|---|---|---|
Score | 4,416 | 5,424 | 1,289 |
こちらは大差がついた。Mozillaが開発に力を入れている証だろう。
総合的なベンチマーク・スイート
Peacekeeper
Peacekeeperは、Futuremarkが提供する老舗のWebベンチマークだ。多角的なテストを行っており、その指標は今なお信頼性を失っていない。
Firefox 31 | Firefox 38 | Chrome 42 | |
---|---|---|---|
Points | 3108 | 4164 | 4143 |
Rendering | 44.63 | 44.79 | 101.57 |
HTML5 Canvas | 35.57 | 43.80 | 44.24 |
Data | 27539.68 | 53947.55 | 71183.91 |
DOM operations | 25686.86 | 27404.90 | 22173.75 |
Text parsing | 258316.57 | 431736.03 | 172128.00 |
Firefox 38が総合ポイントでChrome 42と並んだ。Firefox 31から約34%もの大幅なスコアアップを果たしており、過去の停滞が嘘のような素晴らしい結果といえる。DataやText parsingの項目で伸びが目立つ。
Browsermark
Browsermark 2.1は、フィンランドのBasemark社が提供する総合ベンチマークで、実環境のパフォーマンスを計測することに焦点を当てているという。計測の対象は、CSS、DOM、グラフィックス、JavaScriptなど。
Firefox 31 | Firefox 38 | Chrome 42 | |
---|---|---|---|
Score | 3656 | 4095 | 5657 |
Firefox 38のスコアは順当な伸びを見せているが、Chromeの強さが目立つ。
RoboHornet
RoboHornet RH-A1は、Benchmark.jsベースの総合ベンチマークで、α版だが完成度は高い(FAQ)。標準的なCore Suiteを選んで計測した。
Firefox 31 | Firefox 38 | Chrome 42 | |
---|---|---|---|
RoboHornet index | 97.57 | 102.69 | 168.22 |
Add Rows to Table | 8.06 | 7.26 | 12.00 |
Add Columns to Table | 4.21 | 3.79 | 6.70 |
Descendant Selector | 31.31 | 33.25 | 20.98 |
2D Canvas toDataURL | 3.93 | 4.65 | 15.47 |
2D Canvas clearRect | 3.89 | 3.91 | 12.19 |
innerHTML Table | 4.93 | 4.89 | 5.13 |
Table scrolling | 6.46 | 5.01 | 4.42 |
Resize columns | 7.75 | 6.15 | 25.41 |
Object Scope Access | 2.74 | 2.76 | 2.70 |
ES5 Property Accessors | 1.86 | 7.91 | 5.08 |
Argument instantiation | 3.14 | 2.43 | 9.64 |
Animated GIFS | 0.47 | 1.09 | 0.33 |
offsetHeight triggers reflow | 1.13 | 1.06 | 10.74 |
DOM Range API | 4.79 | 5.60 | 4.51 |
Write to localStorage | 7.67 | 7.71 | 17.76 |
Read from localStorage | 5.25 | 5.24 | 15.15 |
Browsermarkの結果と似たような傾向となった。その中で、Firefox 38において、ES5 Property AccessorsおよびAnimated GIFSの各項目が高い数値を示している点が気になる。過去にlocalStorage関係の項目で数値の大きな変動が見られたこともあっただけに、今後も高い数値を維持できるのか注目される。
WebXPRT 2015
WebXPRT 2015は、米Principled Technologies社が提供するWebベンチマークの最新版である。オフィスワーカー向けWebアプリを念頭に置いたらしきタスク設定となっており、繰り返し実行されることで判定の精度を高めている。以下の表で、総合スコアは数値が大きいほうがよいのに対し、個別の項目は処理に要する時間を示しており、数値が小さい方がよい。なお、ホストはシンガポールのものを利用した。
Firefox 31 | Firefox 38 | Chrome 42 | |
---|---|---|---|
Overall Score | 316 +/- 8 | 367 +/- 18 | 461 +/- 8 |
Photo Enhancement | 386 ミリ秒 +/- 1.37% | 354 ミリ秒 +/- 1.66% | 265 ミリ秒 +/- 3.07% |
Organize Album | 2757 ミリ秒 +/- 16.78% | 2632 ミリ秒 +/- 15.64% | 1633 ミリ秒 +/- 1.19% |
Stock Option Pricing | 387 ミリ秒 +/- 2.65% | 293 ミリ秒 +/- 1.89% | 317 ミリ秒 +/- 2.48% |
Local Notes | 114 ミリ秒 +/- 2.61% | 128 ミリ秒 +/- 27.86% | 194 ミリ秒 +/- 5.39% |
Sales Graphs | 652 ミリ秒 +/- 1.6% | 659 ミリ秒 +/- 1.45% | 497 ミリ秒 +/- 1.57% |
Explore DNA Sequencing | 4082 ミリ秒 +/- 1.29% | 2210 ミリ秒 +/- 4.61% | 980 ミリ秒 +/- 4.56% |
これもBrowsermarkの結果と似たような傾向といえそうだ。Firefox 38には確かに改良の跡がみられるのだが、Chrome 42に追いつくまでには時間がかかるだろう。
総合評価
前回Firefox 31を検証した際、やや物足りない感があり、アーキテクチャの革新に期待したいと述べたわけだが、Firefox 38はその期待に応える仕上がりだと評価できる。いろいろな角度からテストしてみたが、ほぼ全面的にFirefox 31よりも好成績となっており、特にOctane 2.0やPeacekeeperでChrome並みのスコアが出たのは驚きだった。
一般的なWebアプリの処理性能という観点からすると、Chromeと互角に渡り合うのはやや苦しいものの、WebGLと大規模なasm.jsコードという組み合わせでは、おそらくFirefoxが最速となるはずだ。ゲーム・コンテンツがまさにその組み合わせであるのは、偶然ではあるまい。MozillaがFirefoxをWeb上で最高のゲーム・プラットフォームにすべく開発を続けてきたことが、実を結びつつある。
次のESRは、Firefox 45がベースとなる。この時点で、リリース版でもマルチプロセス化(コード名Electrolysis)が実現されているだろうし、64bit版の提供についても進展があるだろう。それでなくても、Firefox Nightly 40はリリースサイクルの後半、動作が高速で快適だった。Firefox 45までの間にどこまで良くなるか、今から楽しみである。