GANCHIKU.com

DOM検索効率化をもう少し追ってみる。

やったよ。やった。ようやくキーボードが届いたよ。ここ3ヶ月、私のキーボードはC-xと]}のキーが壊れていたのだけど、ようやく快適に打てるようになったよ。私の状態を見兼ねて買ってくれた学生時代の恩師の稲葉先生どうもありがとうございます。つーか、そのくらい自分で買えばいいのだけど、なんか買う気がなかなか起こらなくて、ダラダラしてました。。。

で、さっそく簡単なプログラムを書きはじめている。えと、実はまだDOM検索周りを調べているのだけど、一つ疑問があがってきた。それは以下の通り。

childNodesでの検索とfirstChildとnextSiblingの検索について。つまり、どちらでも子ノードを取得することができるのだけど、実際どっちを使ったらいいの?

ググってみるとパフォーマンスを見ている人がいたのだが、childNodesよりも、fistChildを取ってnextSiblingで検索する方が速いということらしい。特に、IE6が良くないとのこと。ブラウザの実装によるのね。。。
new Blah().list(); node.childNodes[] performance
うーむ。てっきりnextSiblingって、いかにもリンクリストな感じでその要素の数を線形探索しないといけないから、O(log(n))で、childNodesでindex指定で取得したら、O(1)で速いんだろうなぁ、なんて思っていたのだけど、どうやらそうでないみたい。。。と鵜呑みにするのもどうか、と思うのだが、まぁ、いいや。

ええと、何でこんなことを調べているかと言うと、私はchildNodesからelementNodeだけの配列を取得するようなメソッドが欲しかったので、作ろうと思っていたのだ。そして、その際に、firstChildからnextSiblingでグルングルン回すか、childNodes分こっちもグルングルン回するかどっちにしようかな、と思っていたのだ。そこで自分でベンチマークを取ってみたよ。まぁ、結局、全てを線形探索するのだから、どっちでもいいような気がするけども。。。で、ベンチマークツールはamachang氏のbenchmark.jsを使用した。

ソースはこんな感じ。ここにサンプルも置いておくよ。childNodes && firstChild + nextSibling Benchmark

< !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

  
    
    
    
    
    
    
    

  
  

childNodes && firstChild + nextSibling Benchmark

firefox2.0.0.7の私の環境での結果は。。。

preparing ...
let's go!
.
*** initialize ***
result : 2763.966739[ms]
.
*** firstChild + nextSibling childElements ***
result : 680.966739[ms]
.
*** childNodes childElements ***
result : 400.966739[ms]
.
*** firstChild + nextSibling childElement ***
result : 48.991075[ms]
.
*** childNodes childElement ***
result : 51.991075[ms]
.
*** prototype.js down + next ***
result : 440.966739[ms]
.
finish!

childNodesの方が速い。まぁ、あんまり変わらないけど、予想と違うぞ?つーか、downとnextの組み合わせ遅すぎ。
ついでにIE6でも見てみる。

preparing ...
let's go!
.
*** initialize ***
result : 67827.967579[ms]
.
*** firstChild + nextSibling childElements ***
result : 1151.967579[ms]
.
*** childNodes childElements ***
result : 14900.967579[ms]
.
*** firstChild + nextSibling childElement ***
result : 59.089179[ms]
.
*** childNodes childElement ***
result : 3354.967579[ms]
.
*** prototype.js down + next ***
result : 22592.967579[ms]
.
finish!

うーん。洒落になってねぇ。ブラウザが死んだかと思たよ。。。childNodes重いっす。。。まぁ、線形探索っぽくchildNodesのitemを見て回っているので、遅くなることはしょうがないのだけど、なんとかならんかな。。。textNodeをすっ飛ばさなくてもいいのだったら、childNodesでindex指定で一発で取れて速そうだけど、今回の目的のelementNodeだけが欲しいならダメだね。こりゃ。

というわけで、firefoxでは、少しだけchildNodesの方が速かったのだけど、IE6のためにfirstChildとnextSiblingを採用するということになりました。。。つーか、downとnextはさらに使いものにならん。。。

prototype.jsのcleanWhitespaceなんかを見てみると、firstChildからnextSiblingを取っているのは理由があったのね。

Shin Ohno 2003-2012