[Tokyo.pm] jus Benkyoukai

[Kazumasa Utashiro]

どうも、反応が遅くて申し訳ありません。いろいろと考えはあるのですが、継
続的に議論したり考えたりする時間が取れないというのが、強く主張するのを
妨げている大きな原因です。ATL-LAX の機内で書いてます。

From: WATANABE Hirofumi <watanabe ＠ ase.ptg.sony.co.jp>
Subject: Re: [Tokyo.pm] jus Benkyoukai
Date: Wed, 8 Sep 1999 10:47:21 +0900

> :jperl の正規表現エンジンは、果たしてこの特長を引き継ぐように実装されて
> :いるのでしょうか? コードを見たわけではありませんが、答はおそらく NO で
> :しょう。実現すれば、メモリ容量的に大きなペナルティを負うはずです。
> 
> 現在の jperl は YES です. メモリ喰います. 文字クラス一回につ
> きだいたい 8KB 使います.

いい加減なことを言ってすみませんでした。ビットマップするんですね。
ASCII が 256バイトなのだとすると、それに比べて数命令程度のペナルティで
検査できるということでしょうか。

8K が大きすぎないかどうかは判断が難しいところです。64K だともちろん話
になりませんが、8K だとしても100回使ってあれば 800K になって、ちょっと
気になる量になってきます。最近はそのくらいは気にしないとしても、500回
で 40M になると、僕が今使っているような主記憶 40M のマシン (DHU2) では
結構なストレスです。ASCII なら、たったの 128K ですからかなりの違いです。

文字クラスが500回出て来るプログラムというのは、もちろん普通ではありま
せんが、自動生成するようなものだと考えられない量ではありません。そのよ
うな「ほとんど起こりそうもないけど、絶対起こらないとは限らない」状況に
どう対応するかは、設計ポリシーの問題でしょう。99% のプログラムでは問題
無いんだからいいじゃないか、という主張する人がいてもおかしくはないと思
います。

実装としては、実際の使われ方を考えると、8K のフラットなテーブルにする
よりも、indirect にした方が、検査速度もメモリ効率も向上するような気が
します。日本語文字コードを前提とするならば、最初のテーブルは128バイト
で足りるでしょう。/[あ-ん]/ みたいな表現なら、128 + 32 バイト程度です
みますね。このような場合は、検査効率を優先して 128 + 256 に最適化する
という手もあります。そう考えてみると、効率的には十分 acceptable な気も
してきました :-)

--utashiro