sedが遅い話のつづき
ありゃそうだっけ、確か両方だったような、と思ったら両方のようですね。正しかったようでよかった。でもさすがにLANG=Cならperlより速いのか。
GNU sed/grepはlocaleに応じてファイルのエンコーディングを決めるので、localeとファイルのエンコーディングにずれがあったとき(処理系が意図とははずれたinvalidな文字列が見られるので)マッチなどの挙動がおかしくなることがあったと思いますし、例外的な文字が出てくると余計に処理も遅くなるんじゃないでしょうか。zundaさんの実験は、そういう部分のノイズがちょっとあるんじゃないかな、と思いました。直感ですけど。
Python の場合もunicode(Unicode文字列)とstr(バイト列)が明確に区別されていて、ファイルの読み込みなどはstrなのでそれほど問題ないと思います。でもstrで処理をせずunicodeに持っていくとすると、処理内容によっては遅くなるかもしれません(がまあ、ふつうに書けばそれほどでもないはず)。
直感ですけど、で済ませるのもなんなので手元の環境(FreeBSD)で試してみたら、grepもsedもぜんぜん遅くなりません(この日記のデータすべて合計した3MBぐらいをかけてみた)。おかしいな。どちらもGNUの筈なんですが……。ただし、sedでLANGをeucJPにしたときだけ明確に遅くなりました。これは内部的にUTF-8で処理をする前提で文字コードを変換しているからではないかという気がします。元ファイルの文字コードがUTF-8のときでもEUC-JPのときでも遅くなりましたが、元々がEUC-JPの方が速かったので、その差はinvalidな文字列が来たときの対処ルーチンかなあ。