[Namazu-devel-ja 1506] Re: mknmz のadd_ key( ), make_phrase_hash() の負荷軽減

[Tadamasa Teranishi]

寺西です。

NOKUBI Takatsugu wrote:
> 
>   私が試したのは単純にハッシュをDBMに置き換えただけです。今思えば、ファ
> イルI/Oの方がオンメモリより遅いに決まっているので、無駄なことをしたな
> と思っています。

というようなコメントをどこかで書いたことを思い出しました。

>   むしろメモリの使用量を抑えるという意味合いのほうが大きそうです。

ええ。高速化というよりはメモリ使用量を減らすとか、巨大データを取り
扱うためには必要になってきますよね。

ところで、DB_File はディスクに書き込まずにオンメモリで処理できる
はず(ファイル名を undef とする)なので、ちょっと試してみましたが、
それでも相当に遅いものでした。

やっぱり
 > sub3のような実装にしておいて、仮置き先の配列に DBM を使え
 > るように
 > してはどうかと考えています。速度低下がひどくなくてメモリ消費が
 > 抑えられるのであれば $ON_MEMORY_MAX 処理に変えることができ
 > るかもしれません。
という方式で、速度低下を抑えつつ、巨大データを扱えるようにする
のが良さそうでした。
 
> > なら、やっぱり逐次出力して、最後にマージが一番速いのか。
> 
>   そういえば、巨大なファイル群のインデックスを作成するときにnmzmergeを
> 駆使してみたのですが、当然ながら単純な雪だるま式(現在のNamazuと同じ手
> 法)よりもトーナメント方式?(この表現でだいたい理解してもらえると思いま
> すが)の方が高速でした。

nmzmerge だと2つのインデックスしかマージできませんし、2つのインデック
スの文書の順番通りに並んでいないことを考慮した上でマージするわけです
から、逐次出力後にマージするよりは効率が悪いはずです。
にも関わらず nmzmerge でも十分今より高速だということですから、
雪だるま式がいかに効率が悪かがわかりますね。

# これは開発当時に想定しているデータサイズよりもはるかに大きな
# データを扱う現状にあっていないだけなんですけどね。

逐次出力後にマージすれはかなり高速化できるでしょうね。互換性もさほど
失われませんが、逐次出力途中で中断した場合に中間ファイルからインデッ
クスを作るツールぐらいはあった方が良いかもしれません。

それとは別に、nmzmerge でマージできるインデックスの数を 3つ以上にも
対応しておくのも良いですね。
--
=====================================================================
寺西 忠勝(TADAMASA TERANISHI)  yw3t-trns ＠ asahi-net.or.jp
http://www.asahi-net.or.jp/~yw3t-trns/index.htm
Key fingerprint =  474E 4D93 8E97 11F6 662D  8A42 17F5 52F4 10E7 D14E