[Tokyo.pm] jus Benkyoukai

[WATANABE Hirofumi]

わたなべです.

Kazumasa Utashiro <utashiro ＠ iij.ad.jp> writes:

:> 現在の jperl は YES です. メモリ喰います. 文字クラス一回につ
:> きだいたい 8KB 使います.
:
:いい加減なことを言ってすみませんでした。ビットマップするんですね。

すみません. 現在は 32+4096+α バイトでした.

:ASCII が 256バイトなのだとすると、それに比べて数命令程度のペナルティで
:検査できるということでしょうか。

そうですね. 8KB だとペナルティなしですけど, ASCII 分と
0x8000 以上の日本語だけを対象にしてるので 4KB になります.
この操作にペナルティがかかります.

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

なんか途中で一桁間違ってる気がするんですけど,
500 回だと 4M ですよね(実際はその半分の 2M).
ASCII だとたったの 16K ですね(って減らしてどうする).

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

実際はずーっとその文字クラスが存在してるわけではないですよね?
free されると思うんですけど.
逆に回数が増えると malloc/free の時間的なコストという問題はあるかも.

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

たしかに sparse なテーブルなんで圧縮しないとまずいなとは思っ
てたんですけど, いままで誰も文句を言う人がいなかったのでその
まま現在に至ってます.
という意味では 99% 問題ないという設計ポリシーになりますね.

-- 
わたなべひろふみ