Mozilla Flux

Mozilla関係の情報に特化したブログです。

Safari 4 Public Betaの実力や如何に

各所で話題になっているとおり、Safari 4 Public Beta(以下Safari 4)がリリースされた。Safariは近年Mac OSの伸張とともにシェアを伸ばしてきており、Firefoxの有力な競争相手だ。これが全面的にバージョンアップしてきたとなれば、触れないわけにはいかない。

ユーザーインターフェイス

Safari 4のデザインやユーザーインターフェイス(UI)については、「もずはっく日記」や「やってMotors」にスクリーンショット付きの記事が出ているため、簡単な記述にとどめておく。

Vistaネイティブのデザイン

Mac出身のSafariが、Windows版でもOSネイティブのルック&フィールを導入したことは、一つのニュースだった。タブを最上段にもってきたうえ、検索バーの右端に二つのアイコンを置いてドロップダウンメニューを表示する形式であることから、Google Chrome(以下Chrome)の影響を受けていることは間違いない。

ただ、メニューバーを廃してページ用のアイコンとブラウザ全体用のアイコンにまとめるデザインは、IE7が最初に持ち込んだものだ。『Vista版Firefoxはメニューバーを自動的に隠すべきか』で述べたように、その背景にはWindows Vistaのデザインガイドラインがあり、ChromeもSafari 4もそれに従ったまでのことである。

したがって、Safari 4が「Windowsアプリとして変」なのではない。極論すれば、OS間でデザインを一貫させることにこだわっているFirefoxのほうが変なのだ。将来のVista/Windows 7版Firefoxは、Safari 4と同様のデザインを選択する可能性がある。

(09/03/05追記)
「もずはっく日記」に『ブラウザごとのWindowsクラシックの再現度』という記事が出た。Safari 4がWindowsのネイティブアプリを名乗るには不十分であることを、他のWebブラウザとも比較しつつ具体的に指摘した素晴らしい内容だ。おすすめである。

Cover Flow

Cover Flowは、iTunesと共通し、Appleのオリジナリティが感じられる優れたUIだ。

しかし、ブックマークを開く際、いちいちCover Flowの画面に飛ぶのはいただけない。ブックマークを使う場面を考えてみると、現在見ているページはそのままに、別のタブにブックマークを開くことを意識しながらメニューを辿ることも多いのではないだろうか。Cover Flow画面への強制的な切り替えは、そうしたワークフローを邪魔してしまう。この点、Firefox 3.2で実装予定のタブプレビューパネルは、タブを切り替える場面で使うので、ユーザーが現在のページを離れると予測しても間違いではない。その意味で、画面を覆う挙動は共通でも、同列に扱うことはできない。

IEやChromeもブックマークを開くときに画面全体を切り替えることはしていない。Safari方式とどちらが主流かは明らかだろう。Safari 4がWindows版でも普及を目指すなら、主流のやり方を意識すべきだ。ブックマークメニュー型をデフォルトとしつつ、ユーザーが簡単な操作でCover Flowに移行できるようにし、その際、デフォルトを変更するか尋ねるのではどうだろうか。

ページの表示性能

Safari 4のレンダリングエンジンが優秀であることは、さまざまなWebページを表示してみればすぐにわかる。Firefox 3.1の最新開発版であるShiretokoと比較しても、互角か、ひょっとするとそれ以上の性能があると思われる。Acid 3テストでもきれいに100/100をマークし、スピードだけでなく正確性も非常に高い。

しかし、現在のところFlash Playerプラグインとの相性問題を抱えているようだ。最新のFlash Player 10.0.22.87をインストールした環境で、YouTubeの動画を再生してみよう。Firefoxを含む他のWebブラウザと比較して、Safari 4は明らかにCPU負荷が高い。このバグが厄介なのは、通常のWebブラウジングにも影響する点だろう。最近のWebサイトは、Flash形式の広告を掲載しているものも多い。CPU負荷がかかるということは、描画が遅くなることを意味する。せっかくレンダリングが速いのに、相殺されてしまうのだ。

Firefoxなら、そうした問題があっても、アドオンで広告をブロックすることによって、暫定的な対処が可能だ。これに対し、Safari 4はアドオンで機能を拡張できないので、バージョンアップを待つしかない。

メモリ管理

Safari 4は、シングルプロセス方式を採用している。同じWebKitをベースにしたChromeがタブごとにプロセスを割り当てているのとは対照的だ。FirefoxとSafariがシングルプロセス方式で、ChromeとIE8がマルチプロセス方式という構図になる。

Firefoxがシングルプロセス方式を維持しているのは、メモリ消費量を抑えるためだ。Safari 4も同じ理由と考えられる。だが、Safari 4は、Shiretokoよりも多くのメモリを消費する。これではあまりメリットが感じられない。Chromeに倣ってマルチプロセス方式にしたほうがよかったかもしれない。

JavaScriptエンジンの処理性能

Safari 4は、「Nitroエンジン」と呼ばれる新たなJavaScriptエンジンを搭載している。これは、SquirrelFish Extremeの名称を変更したものだろう。Firefox 3.1のTraceMonkeyやChromeのV8エンジンと同様に、JIT機能によって高速にJavaScriptを処理できる。

Appleは、その性能がIE7やFirefox 3と比較して高いとアピールしているが、Beta版と正式版を比べるのはフェアではないだろう。また、新機能を紹介したWebページを見ると、その記述には疑問を抱かざるを得ない。

たとえば、Safari 4は、Nitroエンジンの力で「Internet Explorer 7の最大30倍、Firefox 3の3倍以上も高速で動作します」とする一文だ。比較表を見ても、「i-Bench JavaScript」の項目でIE7と約13倍の差があることはわかるが、30倍という数字の根拠は見当たらない。

ちなみに、比較表におけるSunSpiderベンチマークの数値は、おそらくFirefox 3と3.1 Beta 2のそれを取り違えている(グラフは正しい)。しかも、RC1がリリース済みなのに「IE8 Beta」で計測しているばかりか、数値の記載がない点も不自然だ。
(同日追記)
画像をオフにして再確認してみると、「IE8 Beta」は、「IE8 RC1 Beta」の略と判明し、数値も掲載されていた。RCを同時にBetaと呼ぶのは語法として一般的ではないと思うが、RCでベンチマークを取っていたのは確かなので訂正する。
ただ、IE7が「4137.80ミリ秒」でIE8が「19902.20ミリ秒」と記載されており、こちらもおそらく結果を取り違えている(グラフは正しい)。

また、i-Benchでの結果を全面に押し出している点も怪しい。SunSpiderと並ぶ「業界最先端のベンチマークテスト」らしいのだが、ネットで調べてみると、真っ先に出てくるのはMac OS X専用のベンチマークである。これでIEなどを計測したのだとすると、エミュレーションを使っていることになるが、さすがにそれは不正になるのであり得ない。

とすると、英語版Wikipediaに項目のあるiBenchを指しているのだろう。が、このベンチマーク、2003年にiBench 5.0がリリースされた後は開発が停止されているのだ。にもかかわらず、2007年に開かれたWorldwide Developers Conferenceで、Steve Jobs氏が、修正版のiBench 5.0を指して、「最も尊敬できるブラウザベンチマーク」だと賞賛したらしい。今回もそれを使っているものと思われるが、開発が停止されたソフトをAppleが独自に修正し、該当バージョンが未公開なのだから追試ができない。そんなベンチマークでいかに結果が優れていても、眉唾物というほかない。

JavaScriptベンチマーク対決

Appleの発表が当てにならないので、Web上のベンチマークを使って自分で計測してみた。使用したベンチマークは、"SunSpider JavaScript Benchmark"、"V8 Benchmark Suite - version 3"および"Dromaeo: JavaScript Performance Testing"(ただしRecommended Testsのみ)の三つ。

Safari 4がまだ開発版なのだから、これと比較するためのWebブラウザも開発版をもってくるべきだろう。というわけで、次のものでテストした。ただし、計測を行ったタイミングの都合で、現時点の最新版よりは少し古いバージョンであることをお断りしておく。
Shiretoko/3.1b3pre(ID:20090225031913)
Safari 4.0 Public Beta(WebKit/528.16)
Google Chrome 2.0.164.0(WebKit/530.1)

まずはSunSpiderから。WebKitの開発チームが作ったベンチマークであり、Safari 4にとっては有利な土俵のはずだが、結果はChromeの圧勝である。Safari 4もさすがに良好な数値を出しているものの、Firefox 3.1にとっては射程圏内だろう。

他方で、Chrome 2.0に勝つのは難しいと予想される。ちなみに、ここでは記載していないが、Chrome 1.0で計測してみると、Shiretokoとほぼ互角の数字となる。これは、V8エンジンの改良が著しいことを示している。

Shiretoko Safari 4 GC 2.0
Total 2248.8ms +/- 1.4% 1983.0ms +/- 1.3% 1530.6ms +/- 2.2%
3d 300.0ms +/- 2.5% 432.0ms +/- 2.8% 215.6ms +/- 4.2%
access 315.2ms +/- 14.2% 191.4ms +/- 2.0% 117.0ms +/- 2.0%
bitops 72.4ms +/- 3.6% 83.4ms +/- 12.2% 107.8ms +/- 14.2%
controlflow 99.4ms +/- 0.7% 6.4ms +/- 10.6% 4.2ms +/- 24.8%
crypto 139.0ms +/- 3.3% 116.8ms +/- 1.6% 84.0ms +/- 6.0%
date 292.8ms +/- 1.1% 188.0ms +/- 2.2% 231.6ms +/- 4.6%
math 98.0ms +/- 0.9% 323.8ms +/- 0.4% 169.6ms +/- 1.3%
regexp 143.8ms +/- 12.9% 60.2ms +/- 0.9% 29.4ms +/- 2.3%
string 788.2ms +/- 2.0% 581.0ms +/- 0.5% 571.4ms +/- 3.1%

次は、V8ベンチマーク。これはChromeのデモンストレーションのためにあるようなベンチマークなので、順当にChromeが勝った。Safari 4は善戦しているが、大差がついている。

Shiretokoは、TraceMonkeyの苦手分野でJITがうまく働かないため、JITがオフの場合よりもむしろ悪い結果が出てしまっている。Firefox 3.1 Beta 3のコードフリーズまでには、対策用のパッチが入る予定なので、後日またパフォーマンスをチェックしたい。

Shiretoko Safari 4 GC 2.0
Score 71.0 809 1136
Richards 148 1507 1280
DeltaBlue 12.2 1049 1212
Crypto 36.8 1474 1200
RayTrace 105 610 1493
EarleyBoyer 154 1706 2075
RegExp 119 115 372

最後は、Dromaeo。これは、Mozillaが提供しているものだが、DOMの処理も含めた総合性能を計測する点が特徴だ。現在のVersion 3は、従来の方針を転換し、単位時間あたりの処理量を調べるものになっている。しかも、加熱するJavaScriptエンジンの開発競争に追随するため、あえてヘビーな処理を多数加えており、計測に時間がかかる。

手元の環境では、頻繁に処理落ちが発生するため、結果の精度は低いとみられる。それでも、Chrome 2.0での進行は比較的スムーズだった。V8はかなり筋のいいエンジンである。なお、実際には詳細な結果が表示されるのだが、項目が多すぎるので、今回は総合スコアだけを記載する。

Shiretoko Safari 4 GC 2.0
Total 11.17runs/s 10.10runs/s 56.74runs/s

終わってみれば、Chrome 2.0の一人勝ちで、他のWebブラウザを一歩も二歩もリードしていることが明らかになった。絶対的な性能で見ればTraceMonkeyも高いのだが、開発競争でやや後れをとっているのは残念なところだ。

とくに、Mozilla謹製のDromaeoでChromeに完敗したのは痛い。このベンチマークの結果は、実際のWebアプリケーションの処理を推測する有力な材料になるからだ。Firefox 3.1正式版のリリースまでに改善を期待したい。

Safari 4に話を戻すと、たしかに性能は高いが、驚くほどではない。ベンチマークの項目を詳細に眺めると、TraceMonkeyに大きく劣る個所もあり、まだまだ改善の余地がある。ただ、Webブラウザ同士がしのぎを削る熾烈な争いにおいて、最前線で戦えるだけの実力は備えているといえよう。

(09/02/28追記)
Mozilla Japanのdynamisさんと中野雅之さんからコメントを頂戴した。ベンチマークの意義や、「Windowsネイティブ」とは何かということについて興味がおありの方は、ぜひご一読ください。