フォルダツリー表現で、dhtmlXTreeを採用したのはいいが、「果たしてどれくらいのノードを扱えるのか？」実験してみた。
結果：
1000のノードからなる、計163Kbのxmlを読み込んだ場合。
→「このページのスクリプトがInternetExplorerの実行速度を遅くしています。スクリプトを実行し続けると、コンピュータが応答しなくなる可能性があります。スクリプトを中断しますか？」 [はい（Y）] [いいえ（N）]
読み込み開始から25秒で上記ダイアログが出て、続行してから8秒で描画完了した。
ノードが100程度なら結構瞬時に切り替わる程度のパフォーマンスであるので、静的XMLファイルからツリーを構成する場合は、このくらいに留めておいたほうが良さそう。
でかいフォルダツリー階層を、サーバサイドでDB生成するなら、autoLoadingを使って、必要な部分だけを描画した方が良い。
Javascriptで配列を使って描画するツリーを使っていた時にも、3000個のフォルダを描画しようとしたら、「ブラウザクラッシャーか？」というくらい、重かった。（汗）
WindowsExplorerでも、”あるフォルダの下に1000個もフォルダがあると、なかなか帰ってこない”ので、フォルダ階層として1000個もノードがあるという分類自体が何か間違っているに違いない。
その後
dhtmlxTreeのドキュメントでSmartXMLParsingというメソッドが存在することを知る。
tree.enableSmartXMLParsing(true)なんて書けばよいらしい。
※実際に早くなったような気がしないんだけどなぁ・・・使い方間違ってるのかなぁ・・・（ボソ）
