当ブログでは、Firefoxの延長サポート版（ESR）のメジャーアップデート時期を開発の区切りとみて、Web上で実行可能なベンチマークの測定結果を公開している。今回は、Firefox 52のパフォーマンスをFirefox 45と比較してみたい。
この1年の間にマルチプロセス機能（e10s）が初期設定で有効化されるところまできた一方で、64bit版の本格投入は数バージョン先になる。そこで、今回は32bit版のみを対象としつつ、e10sの有無による差をテストすることにした。検証を行った具体的なバージョンを挙げると、32bit版のFirefox 45.7.0（ビルドID：20170118123525）および32bit版のFirefox 52.0 RC2（ビルドID：20170302120751）である。後者はさらにbrowser.tabs.remote.force-enableの設定を追加して値をtrueにしたもの（e10sオン）と、そうでないもの（e10sオフ）に分かれる。
動作環境についてだが、OSは64bit版Windows 10 Professional（Anniversary Update）で、使用したハードウエアは、CPUがIntel Core i7-7500U CPU 2.70GHz、GPUがIntel HD Graphics 620（ドライバのバージョン：21.20.16.4542）、メモリ容量が16.0GB、ストレージがWestern Digital製SATA-IIIのHDDである。GPU描画支援はDirect3D 11、Direct2D 1.1とDirectWriteをバックエンドに使用している。
測定にあたって対象ごとに新規プロファイルを用意し、初期設定からフォントをメイリオに変更したほか、dom.max_script_run_timeの値を0にした（テストが途中で中断されるのを防ぐため）。また、拡張機能はすべて無効化し、プラグインは自動的にインストール・有効化されるものを除きShockwave Flash 24.0 r0だけを常時有効化している。
測定の際には、Turbo Boost機能を無効化し、定格の動作周波数でPCを動作させた。画面サイズは3840×2160で、表示を250％に拡大しており、測定の際のウィンドウは最大化している。なお、各ベンチマークの実行後はFirefoxを終了させて、メモリ上に前のベンチマークが残らないようにした。
最後に、対象となるベンチマークは、前回の記事で用いたものから一部を入れ替えた。
ページの読み込み速度およびメモリ使用量
10のWebサイト*1を同時に開いて、読み込み中であることを示すアイコン（throbber）が消えるまでの時間を手動で計測した。秒数の小数点以下は切上げている。同時に、10サイトを表示させた場合と、単サイトを表示した場合のメモリ使用量もチェックした。
具体的な手順は次のとおり。以下の10サイトをその記載順にフォルダ内にブックマークしたバックアップファイル（JSON形式）をインポートし、「タブですべて開く」で10サイトをいっせいに読み込む。throbberが消えるまでの時間を計測し、完了したらFirefoxのホームページは閉じ、各タブをクリックしてWebページを実際に画面に表示させる。つまり最後に表示されるのはWikipedia（日本語版）になる。
1分間そのまま放置した後、新しいタブを開いてabout:memoryを呼び出し、"Show memory reports"欄のMeasureボタンをクリックし、Main Processのresidentの値を見る。ただし、e10sが有効化された環境では、子プロセスのresident-uniqueの値も合算する*2。
そして、「他のタブをすべて閉じる」でYahoo! JAPAN以外のWebページはすべて閉じる。5分間*3そのまま放置した後、再び新しいタブを開き、about:memoryを呼びだしてMain Processのresidentの値を（e10sオンのときは子プロセスのresident-uniqueの値も）見る。Firefoxをいったん終了させ、再起動後に上記10サイトを同じ手順で開いて、throbberが消えるまでの時間を計測する。一連の手順を実行した結果を以下に示す。
| |
Fx 45 ESR |
Fx 52 STD |
Fx 52 e10s |
| 読込時間（1回目） |
32 秒 |
27 秒 |
28 秒 |
| 読込時間（2回目） |
18 秒 |
19 秒 |
21 秒 |
| |
Fx 45 ESR |
Fx 52 STD |
Fx 52 e10s |
| 使用メモリ(10タブ) |
590.81 MB |
553.88 MB |
674.32 MB |
| 使用メモリ(単タブ) |
395.66 MB |
349.95 MB |
418.44 MB |
読み込み速度、メモリ使用量ともにFirefox 52の非e10s版が優れている。e10sを有効化すると使用メモリが2割程度増えるが、Firefox 45よりも省メモリ化が進んでいることもあり、思ったほどメモリは喰われなかった。
ストレージ
HTML5 Offline Storage Benchmarkは、オフラインストレージの性能を計測するベンチマークだ。localStorage、WebSQLおよびIndexedDBを対象にできるが、ここではIndexedDBの結果（主に1ミリ秒あたりに処理されたオペレーション数）を掲載する。
| |
Fx 45 ESR |
Fx 52 STD |
Fx 52 e10s |
| Clear |
16.25 ms |
15.88 ms |
15.69 ms |
| Inject-L |
0.38 op/ms |
2.62 op/ms |
2.39 op/ms |
| Inject-S |
0.82 op/ms |
3.19 op/ms |
1.33 op/ms |
| InjectBulk-L |
1.37 op/ms |
1.86 op/ms |
2.23 op/ms |
| InjectBulk-S |
6.02 op/ms |
5.94 op/ms |
6.05 op/ms |
| Lookup |
8.33 op/ms |
5.84 op/ms |
5.56 op/ms |
| Lookup2 |
11.74 op/ms |
9.53 op/ms |
7.05 op/ms |
Firefox 52になって改善された部分もあれば、悪化した部分もあるが、非e10s版では改善された項目のほうが多い。Snappyライブラリのアップデート（Bug 768074）が影響しているかもしれない。ただ、e10sを有効化すると若干パフォーマンスが落ちるようだ。
レイアウトおよび描画処理
HTML5 Canvas
CanvasMark 2013 version 1.1は、HTML5ゲームでよく使用される処理（ビットマップ、Canvas描画、αブレンディングなど）に対するレンダリング・パフォーマンスをテストする。
| |
Fx 45 ESR |
Fx 52 STD |
Fx 52 e10s |
| CanvasMark Score |
9861 |
9759 |
9679 |
残念ながらFirefox 52で若干スコアが下がっており、e10sが有効になるとさらに下がる。
WebGL
Microsoft Edge TestDrive demosからFishGLをピックアップし、水槽内の魚の数を150匹に設定してテストを実行した。 このテストは、主にWebGLに関する処理性能を測定する。
| |
Fx 45 ESR |
Fx 52 STD |
Fx 52 e10s |
| 秒間フレーム数 |
15 - 17 fps |
16 - 17 fps |
18 - 19 fps |
大きな差はつかないものの、Firefox 52のe10s版がトップに立った。実際にフレームレートの動きを見てもらうとわかるが、安定度でもe10s版が優れている。
次に、Unity WebGL Benchmarks 2015年版での結果を見てみよう。このベンチマークは、Unityの開発したグラフィックスエンジンが一定時間内にどの程度のタスクを処理できるかをテストするものだ。Unity Blogの記事によれば、Unity 5.3がベースになっているらしい。
| |
Fx 45 ESR |
Fx 52 STD |
Fx 52 e10s |
| Overall Score |
48634 |
45417 |
45684 |
Firefox 52の成績が悪い。e10sの有効・無効による差は誤差のレベルにとどまる。
最後に、OortOnline.gl v0.2.2でテストを行う。新しく加わったこのベンチマークは、Oort Onlineというオンラインゲームの世界を再現し、典型的なWebGLゲームの描画パフォーマンスを測定するという。
| |
Fx 45 ESR |
Fx 52 STD |
Fx 52 e10s |
| Total Score |
4060 |
4220 |
3850 |
Firefox 52の非e10s版が良い結果を収める一方、e10s版はFirefox 45よりもスコアで劣ることになってしまった。
JavaScript/DOM処理
JavaScript
Octane JavaScript Benchmark は、Google製のJavaScriptベンチマークで、バージョン2.0はスループットに加えてレイテンシも重視している。言い換えれば、Webアプリのピーク性能だけでなく、動作のスムーズさも評価の対象となる。
| |
Fx 45 ESR |
Fx 52 STD |
Fx 52 e10s |
| Octane Score |
20802 |
20765 |
20369 |
| Richards |
26169 |
26325 |
24817 |
| Deltablue |
34110 |
34038 |
39658 |
| Crypto |
22533 |
22070 |
21507 |
| Raytrace |
84507 |
79475 |
76885 |
| EarleyBoyer |
29506 |
28134 |
26960 |
| Regexp |
2521 |
3034 |
3085 |
| Splay |
15972 |
14872 |
13479 |
| SplayLatency |
18632 |
13668 |
14429 |
| NavierStokes |
21666 |
22740 |
23229 |
| pdf.js |
10389 |
8469 |
9868 |
| Mandreel |
17872 |
17207 |
15528 |
| MandreelLatency |
19550 |
18062 |
18261 |
| GB Emulator |
40996 |
45719 |
36439 |
| CodeLoad |
8680 |
11354 |
12421 |
| Box2DWeb |
25458 |
30844 |
27680 |
| zlib |
50938 |
46747 |
47194 |
| Typescript |
18729 |
20320 |
17682 |
Firefox 52 非e10s版の総合スコアはFirefox 45と同程度だが、個別の項目を見ると、上がったり下がったりしているので、たまたま近い結果になっただけのようだ。Mozillaは、CacheIRと呼ばれる仕組みを導入し、 BaselineとIonMonkeyの間でインラインキャッシュ（IC）の処理を共通化しようとしているが、目に見える成果が出るのは、まだ先なのだろう。
他方、e10s版はやや劣る結果となった。個別の項目の傾向は非e10s版と一致しておらず興味深い。
次に、JetStream 1.1を採り上げる。JetStreamはWebKitチームが提供するベンチマーク・スイートで、SunSpider 1.0.2やOctane 2.0からも一部のベンチマークを取り入れ、スループットとレイテンシの双方を計測する。
| |
Fx 45 ESR |
Fx 52 STD |
Fx 52 e10s |
| Score |
142.18 ± 3.0406 |
137.55 ± 2.2040 |
133.12 ± 2.5195 |
Firefox 52でスコアが落ち込み、e10sの有効化でさらに下がるという良くないパターンに陥っている。
JavaScript＋DOM
Speedometer 1.0は、WebKitチームが提供するベンチマーク・スイートで、DOMオブジェクトの操作に焦点を当て、Webアプリの応答性を測定する。jQueryなど6つのポピュラーなJavaScriptフレームワークを採用し、ユーザーの行動をシミュレートするという。GoogleのV8開発チームが、Octaneよりも実環境に近いスコアが出るとお墨付きを与えたエピソードもある。
| |
Fx 45 ESR |
Fx 52 STD |
Fx 52 e10s |
| Runs / Minute |
42.9 ± 0.87 |
41.7 ± 0.56 |
41.83 ± 0.36 |
若干だがFirefox 52が劣る結果となった。e10sの有無による差はほぼなさそうだ。
次に、Esprima: Speed Comparisonsは、各種JavaScriptパーザを用いて、jQuery.Mobile 1.4.2、Angular 1.2.5およびReact 0.13.3という3つのフレームワークを処理させた結果を示すものだ。Esprimaの作者が、自作のパーザの優秀さを示す目的で作成したベンチマークのようだが、ここではEsprima 3.1.3による処理結果のみを掲載する。
| |
Fx 45 ESR |
Fx 52 STD |
Fx 52 e10s |
| 処理時間(ミリ秒) |
307.1 ms |
304.6 ms |
301.0 ms |
Firefox 52で処理時間が短縮され、e10s有効化でさらに短縮されるという良いパターンだ。ただ、速度向上の程度はそれほど大きくない。
asm.js
Emscriptenプロジェクトの一環として公開されているベンチマーク・スイートMASSIVE v1.2を走らせて、asm.jsの処理性能を見る。このベンチマークは大規模なasm.jsコードに特化しており、Poppler、SQLite、LuaとBox2Dのコードをベースに、スループットだけでなく、読み込み時間や読み込み中の応答性、パフォーマンスの一貫性なども計測対象とする。
| |
Fx 45 ESR |
Fx 52 STD |
Fx 52 e10s |
| Score |
4929 |
4856 |
4975 |
Firefox 52でスコアがいったん落ち込むが、e10sを有効にすると盛り返すという不思議な結果に。MozillaはWebAssemblyの開発に力を入れており、Firefoxの処理能力はChromeやSafariを凌ぐほどだが、asm.jsの処理に関しては据置きといったところか。
総合的なベンチマーク・スイート
MotionMark
新たに加わったMotionMark 1.0は、WebKitチームが提供するベンチマーク・スイートで、複雑なシーンを目標フレームレートでアニメーションさせる能力を測定する。描画処理のパフォーマンスに焦点を当ててはいるものの、重いテストであり、ブラウザの総合力が問われそうだ。画面サイズがMedium（900 x 600）の場合の結果は、以下のようになった。
| |
Fx 45 ESR |
Fx 52 STD |
Fx 52 e10s |
| Score |
127.02 ± 3.71% |
98.63 ± 4.72% |
96.76 ± 1.87% |
| Multiply |
62.48 ± 5.76% |
119.84 ± 3.53% |
117.41 ± 1.51% |
| Canvas Arcs |
722.68 ± 1.17% |
703.10 ± 1.60% |
705.42 ± 1.11% |
| Leaves |
159.17 ± 7.78% |
150.33 ± 4.47% |
135.42 ± 2.15% |
| Paths |
2297.41 ± 1.30% |
2291.85 ± 0.82% |
2268.73 ± 0.98% |
| Canvas Lines |
1905.91 ± 2.01% |
1804.97 ± 0.80% |
1760.05 ± 0.96% |
| Focus |
6.81 ± 2.16% |
6.66 ± 2.21% |
6.79 ± 1.54% |
| Images |
20.57 ± 5.38% |
15.30 ± 23.45% |
15.82 ± 3.75% |
| Design |
12.43 ± 4.04% |
5.66 ± 2.77% |
5.57 ± 3.16% |
| Suits |
157.22 ± 7.77% |
29.23 ± 1.71% |
27.75 ± 2.34% |
Firefox 52では一部の項目でスコアが大幅に低下しており、そこが足を引っ張ったため、総合スコアでも大差がついた。e10sが有効だとダメ押しで下がってしまい、厳しい結果である。
Basemark Web
Basemark Web 3.0は、フィンランドのBasemark社が提供する総合ベンチマークで、従来はBrowsermarkの名称が用いられていた。最新のWeb標準と機能を用いて実環境のパフォーマンスを計測できるというのがセールスポイントで、WebGL 2.0を用いたテストもある。以下はConformanceとBatteryの各テストを除いて実行させた結果だ。
| |
Fx 45 ESR |
Fx 52 STD |
Fx 52 e10s |
| Score |
N/A |
237.66 |
269.57 |
Firefox 45はWebGL 2.0テストが実行できなかったので、Firefox 52のスコアだけを掲載した。e10sを有効化すると約13％もスコアが上昇しており、今回の一連のベンチマークの中では異色と言える。
RoboHornet
RoboHornet RH-A1は、Benchmark.jsベースの総合ベンチマークで、α版だが完成度は高い（FAQ）。ここでは、標準的なCore Suiteを選んで計測した。
| |
Fx 45 ESR |
Fx 52 STD |
Fx 52 e10s |
| RoboHornet index |
99.93 |
90.87 |
93.33 |
| Add Rows to Table |
3.44 |
3.43 |
5.14 |
| Add Columns to Table |
1.68 |
1.97 |
2.51 |
| Descendant Selector |
30.74 |
26.11 |
22.10 |
| 2D Canvas toDataURL |
5.05 |
5.02 |
4.95 |
| 2D Canvas clearRect |
4.97 |
4.83 |
4.65 |
| innerHTML Table |
4.03 |
3.32 |
2.80 |
| Table scrolling |
6.11 |
4.26 |
4.33 |
| Resize columns |
6.15 |
5.35 |
5.14 |
| Object Scope Access |
3.23 |
3.28 |
3.00 |
| ES5 Property Accessors |
13.87 |
13.60 |
17.83 |
| Argument instantiation |
2.79 |
1.73 |
1.74 |
| Animated GIFS |
0.76 |
0.66 |
0.78 |
| offsetHeight triggers reflow |
1.26 |
1.51 |
1.57 |
| DOM Range API |
3.53 |
3.32 |
4.17 |
| Write to localStorage |
7.36 |
7.54 |
7.68 |
| Read from localStorage |
4.96 |
4.96 |
4.94 |
Firefox 52で総合スコアが低下した点が目立つ。e10sを有効化すると多少改善されるものの、Descendant Selectorの項目で足を引っ張られてしまい、伸び悩んだ。
WebXPRT 2015
WebXPRT 2015 v1.998.2は、米Principled Technologies社が提供するWebベンチマークである。オフィスワーカー向けWebアプリを念頭に置いたらしきタスク設定となっており、各ベンチマークを繰り返し7回実行することで、判定の精度を高めている。以下の表で、総合スコアは数値が大きいほうがよいのに対し、個別の項目は処理に要する時間（ミリ秒）を示しており、数値が小さい方がよい。
| |
Fx 45 ESR |
Fx 52 STD |
Fx 52 e10s |
| Overall Score |
372 ± 11 |
319 ± 9 |
328 ± 9 |
| Photo Enhancement |
347ms ± 11.04% |
342ms ± 7.48% |
314ms ± 9.38% |
| Organize Album |
1920ms ± 8.36% |
1972ms ± 6.49% |
1977ms ± 8.14% |
| Stock Option Pricing |
326ms ± 9.22% |
332ms ± 6.61% |
323ms ± 5.83% |
| Local Notes |
110ms ± 10.06% |
158ms ± 9.29% |
161ms ± 8.93% |
| Sales Graphs |
622ms ± 7.63% |
701ms ± 7.92% |
670ms ± 1.1% |
| Explore DNA Sequencing |
3176ms ± 5.34% |
4711ms ± 6% |
4663ms ± 7.19% |
RoboHornetと同じ傾向が見られる。Explore DNA SequencingやLocal Notesの項目でFirefox 45よりも明らかに処理速度が低下しており、総合スコアにも響いたとみられる。
総合評価
全般的に、Firefox 52の成績は振るわなかった。過去を振り返ると、Firefox 38がほぼ全面的にFirefox 31よりも好成績となっていたのに対し、Firefox 45はスコアが伸びたベンチマークもあれば逆のものもあって、すっきりしない感じになっており、重量級のベンチマークで底力を見せて面目を保っていた。しかし、Firefox 52は、Firefox 45よりも劣る結果となったケースがあまりにも多い。
e10sの有効化に関しても、消費メモリの20％増加と、おそらくプロセス分離のオーバーヘッドがもたらすパフォーマンスの低下が突き付けられた形だ。ただ、Basemark Webのように希望の持てる結果も一部では出ている。いずれにせよ、ベンチマーク結果を眺めていると、e10sを有効化したFirefoxは別のブラウザのような印象を受ける。
この1年間、Mozillaはe10sの段階的導入やWebAssemblyの実装などにリソースを取られすぎたのかもしれない。それとも、性能が頭打ちになりつつあり、従来のような漸進的な手法では改善が見込めないところまで来ているのだろうか。MozillaがQuantumプロジェクトに賭けているのは、そうした状況を打破する面もある、というのは深読みのしすぎか。
次のESRは、Firefox 59がベースとなる。この時点で、Quantum Compositor（GPUプロセス）とQuantum CSS（Stylo）は当然有効化されているだろう。MozillaがQuantum Renderの開発を急ピッチで進めているところからすると、これも有効化までいくかもしれない。また、64bit版が主流になっていることは間違いないし、Flashプラグインは初期設定で無効化されている可能性が高い。旧来型アドオンと訣別するなど代償が大きいだけに、パフォーマンスの飛躍的な向上を期待したい。
