もずはっく日記(2005年12月)

ブラウザのレンダリングエンジンの速度比較、使用メモリ容量比較
初回投稿日時: 2005年12月07日03時10分47秒
カテゴリ: 雑談
SNS: Tweet (list)

時々、Trident(IE)、Gecko(Firefox)、Presto(Opera)等のレンダリングの速度を比較している人を見かけるが、これはある意味ナンセンス。確かに、これらはアプリケーションとして存在するので結果、一定条件下での速度差を出すことはできるが、スタートラインが同じ位置にあるという前提に比較している人が多いように思う。(別に速度比較を無意味、意義の無いこととは言っていないことに注意して欲しい。)

GeckoとPrestoの比較はちょっと難しいので、話を単純にする為に、TridentとGeckoの内部処理について考えてみる。さらに、もっと単純にするためにCSSの値についてのみ考えてみると、これらのエンジンのサポートしているプロパティ数、さらにその値の数が全然違うのは誰もが知っている常識である。CSSのプロパティは各ボックス(要素ではなく、CSSのボックス単位であることに注意)ごとに、全てのプロパティに値が存在しており、実際、保存されている。これは、初期値や、ブラウザのスタイルシート、ページ作者のスタイルシート、ユーザスタイルシートから決定される。このうち、スタイルシートによる指定は、セレクタが絡んでくるのでさらに速度に差が出る。Tridentのセレクタサポートは非常に貧相だが、GeckoはCSS3レベルに近づきつつある。つまり、Geckoでは複雑なセレクタも処理してプロパティ値が決定されることになる分、やはり不利である。

状況を整理してみよう。 二つのエンジンにおいて処理しなくてはいけないCSSプロパティの数にそもそも差がある。プロパティ値を決めるセレクタの対応状況に差があるので、値を決めるのに必要なコストにも差がある。つまり、高機能なエンジンであればあるほど、速度面、メモリ消費量では不利になっていくということだ。

セレクタの問題は両方のエンジンでしか解釈できないセレクタを用いることである程度無視できるだろう。だが、プロパティ数についてはいかんともしがたい。サポートするプロパティ数が増えればその分、一つのボックスあたりのメモリ容量が増えてしまうし、値を決定しなくてはいけない処理対象の数が増えるのだから明らかに処理時間も長くなる。更に、より多くのCSSプロパティをサポートしているということは、実際のレンダリングにおいて、より複雑な描画に耐えうるレンダリング処理を走らせるということになる。つまり、そもそも比較対象の条件が全然平等ではないところに問題がある。

最も、これはユーザの問題ではない。だから、Tridentの描画がGeckoよりも速いことがあったなら、そのユーザにとってはTridentの方がGeckoよりも高速に動作するエンジンであるということは確かだ。それは否定できない。ただし、もし同じ速度で描画されたとしたら、実際には(そのケースにおいては)Geckoの方が実速度は速かった、ということになることにも注意してもらいたい。

実際のレイアウト、レンダリングにおいては極力複雑なCSS対応のコードを別の関数に追い出すなどしてシンプルなレンダリング結果しか必要ないときはシンプルな処理で済むように作っている。ただ、CSSのこの根幹部分は原理的にケチりようが無いというのは悩ましい問題である。

現在のエンジンがCSSをベースに作られているということは、HTMLのtableレイアウトというのは、CSSレイアウトなら必要の無い無駄なボックス(例えばマージンを確保するために、余計なセルを作ったり、スペーサーとよばれる画像を置いたり)を生成するので、実にユーザにとって迷惑なことだというのが、こういう側面からも分かる。