7bit

GUI grepツールの調査過程は一応一段落し、当初のもくろみ通り製作に入ろうとしています。
今は特に苦もなく使えそうなPython, C++, C#のどれを用いるか検討中。
大量のファイルへのアクセスと正規表現のマッチは割と重い処理になりそうなので、実際にコードを書いて比較しています。

まず生grep。find | xargs grep ‘…’。直接Cで書かれていることを考えると、最速の基準として考えて良さそうです。日英対訳文対応付けデータをデータセットとして実験していますが、1.1秒くらいで2000ファイル近くのスキャンが終わる。

次に、書きやすそうなところでPython (re)でやってみました。所詮LLだし、結果には全然期待していません。
ところがところが、何故かこれが滅茶苦茶速い。
特に最適化したコードの書き方でもないんですが、1.6秒くらいで終わる。殆どC同等の速さ。

そして生grepの次に速いだろうと予測していたC++の実験。
正規表現はboost.regex、Unicodeのエンコーディング変換はICU。同じコードを言語を変えて書くのは結構苦痛だなあと思いつつも、ICUとかはじめて使うので得ることもあるにはある。
何時間かかけていよいよ書き上がり、実行してみると…

20秒。絶望的に遅い。

さすがにこれはもう少し速くなるはず。ファイル読み込み、エンコーディング変換、正規表現で検索、と切り分けて原因を探す。
すると、どうやらファイルのリードでwhileなんかを使っていたのが効いていたようで、read(&buf, len)にしたら4秒にまで縮まりました。

しかしPythonの2倍以上かかるのはやはり不満。
文字コード変換・正規表現を両方オフにして、ファイル読み込みだけの時間を計ると0.5秒。
文字コード変換を加えると2.4秒、全部入りで4秒、という感じ。

ちなみにPythonでリードだけなら0.6秒、+変換で計ると1.3秒、全部で1.6秒。

まとめると下表のようになる。

つまり自分では手出しできない、ライブラリ使っている文字コード変換と正規表現が遅い。
UConverterは先に作ってるし、正規表現もコンパイル済みを使い回しているのに…

リードと変換を同時に行えば、文字列をパースする回数を減らせるので少し速くなるかもしれません。
しかしそれでも次の正規表現でがた落ち。

生grepを考えると頑張ってPythonを抜いても壁がすぐ近くにありそうなので、
C++は諦めてPythonで書くかもしれません。
より楽な言語で書けて嬉しいといえば嬉しいんですが、長年使っていたC++がこのざまというのは…

なんだかC#を評価する気力もなくなってきた。
実験のコードなどはたぶんそのうちおそらく公開します。

20090627 追記
C++とPythonの文字コード変換+正規表現速度比較ソース公開
ソースコード公開しました。

C#との比較も(忘れていたけれど)ありました。上のソースコードzipにも加えました。