airheadの日記： memo: リングノードベンチマーク

リングノードベンチマーク - どう書く？org から。せっかくなので値の受け渡し方法を変えてみたり（list 1-4, 5, 6、doukaku.orgに投稿したのはlist 4）、いろいろな条件で計測してみたりしたところ、ブラウザの傾向が垣間見えて面白かった。調子に乗って、5回計測して平均を取るまでしてしまった。

(07/12 13:30 追記) list 6を追加

n*m = 1000*1000
          list1   list2   list3   list4
---------------------------------------
FF3.5.0
  old      7521    4264    1670    1608
  new      4262    3369    1459    1403
FF3.5.0 safemode
  old      1936    1077    1311    1346
  new      1805     992    1458    1397
Op 9.64    2047     869     767     615
Op 10b     2003     878     709     631
IE 6      19238    5106    5544    5240 [ms]

Window 2000 + Pen4 2.53GHz

Firefoxにおいて、oldとあるのは現在常用しているプロファイルでの、newは新規プロファイルでの実行結果。常用プロファイルはFireBugなどアドオンが数多く入っているが、FireBugを無効にするだけで新規プロファイルとほぼ同等まで改善する（FireBugのページごとのオンオフのUIで無効にするのではなく、アドオンマネージャでFireBugを無効にする必要がある）。FireBugは他のアドオンのエラーを検出することもあるが、そうした動作が影響しているのかもしれない。

セーフモードではさらに速度が向上するが、この理由はよくわからない。通常モードにおいてアドオンマネージャで拡張・プラグインをすべて無効にしても、セーフモードほどの数値は出なかった。

Operaでは、Firefoxの通常モードの倍以上速い数値が出たが、総ノード数を大きくしていくに従ってのオブジェクト生成の速度低下がFirefoxよりも顕著である（下表create）。ただし一旦生成してしまえば、ノードのオブジェクト呼び出しにおける速度低下はまったくといってよいほど見られない（下表call）。

n*m      5e4*20  1e5*10   5e5*2   1e6*1
---------------------------------------
FF3.5.0 new
  create    143     284    1583    3765
  call     1514    1559    1616    1631
Op 10b
  create    210     462    5281   16750
  call      784     772     781     784

list1-4ではノードを配列に格納しているが、配列の大きさによる影響は思いのほか少ないないようだ。list5のように、参照を張ることのみでオブジェクトを維持して巨大配列の生成を回避しても、速度低下を大きく改善することはできなかった。総オブジェクト数に依存しての速度低下だろうが、100万もオブジェクトを生成することはまれだろうし（200-250MBもメモリを消費する）、問題になることは少ないだろう。

書き忘れていたlist 6を追加した。もっとも素直に実装すればこの形になるかと思うが、オブジェクトにプロパティmsgがつき、若干ではあるがlist 3よりも遅くなる。