2006年10月26日

[Namazu-devel-ja 1325] Re: mknmz の処理時間短縮

寺西です。

Yukio USUDA wrote:
>
> > この結果からすると、$ON_MEMORY_MAX を 2桁ほど増や
> > すと、高速化しま
> > せんか?
>

> 2.0.17RC2 の mknmz で $ON_MEMORY_MAX を 2桁増
> やして試しました。
> 処理時間が半分程度になりました。
> いろいろ考えさせられる結果です。

やっぱり速くなりましたか。

> ・ conf.pl の初期値が今の時代のマシンスペックに合っていない
>  直しておいてはどうか

厳密にいうとマシンスペックには関係ありません。
取り扱うドキュメントの総量に依存します。

> ・こんな簡単に速くなるのならばFAQに書いておくべきだ
> ・環境を調べて推奨設定を書き出すツールを作ってはどうか
> ・ボトルネックは他にあったようだ

過去にもちょろっと書いたのですが。

mknmz が遅い最大の理由は、中間ファイルの書き出しにあります。
これは読込んだファイルサイズが $ON_MEMORY_MAX を越える度に発生し
ます。
ゆえに大量のファイルを処理すれば中間ファイルの書き出しが頻繁に
発生することになります。

$ON_MEMORY_MAX は、その変数名から想像するようなメモリサイズとは
何ら関係ありません。当然、物理メモリサイズとの因果関係は何も
ありません。

1.x のころは別の名前だったような気がしますが、2.x で変数名変わった
ために誤解され、本来の意味とは違う意味の変数だと思われています。
# それは仕方がない。

話を戻して、中間ファイルの書き出しですが、これは全データを書き出し
を行いますので、1回目よりは2回目、2回目よりは3回目の方が遅いのです。
しかも、O(n) ではないので、データ量が増えれば増えるだけどんどん
遅くなります。
その結果、中間ファイルを頻繁に書き出すと、雪だるま式に中間ファイル
の書き出しに大部分の時間を割かれることになってしまいます。

1,200 で半分くらいになったということなら、10,000 ぐらいなら
$ON_MEMORY_MAX を更に一桁増やすと(オーバーフローしなければ)
4割とかの時間で mknmz の処理が終わるかもしれませんね。
--
=====================================================================
寺西 忠勝(TADAMASA TERANISHI) yw3t-trns@xxxxx
http://www.asahi-net.or.jp/~yw3t-trns/index.htm
Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E

_______________________________________________
Namazu-devel-ja mailing list
Namazu-devel-ja@xxxxx
http://www.namazu.org/cgi-bin/mailman/listinfo/namazu-devel-ja

投稿者 xml-rpc : 2006年10月26日 02:17
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/48298
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。