TSperl 発言

極悪です。

# Reply-To ヘッダが TSperl になってないので返信しにくいです。

すみません、気が付きませんでした。お家からなので今度は大丈夫
でしょう。

>> 計算するよりも LUT 使うほうがリソース（メモリ）は食うけどス
>> ピードは速いって気もしますが、違うのでしょうか。ハードで入力
>> 16bit x 出力 16bit ならストレートで突っ込んでも 100MHz ＝ １
>> 億文字／秒で変換できそうなもんだけど。LUT のサイズは 128KB 
>> くらいだし。
>
>まずテーブルを読みこむオーバーヘッドがありそうで、あとはテーブル参照のア
>ルゴリズムに依存しそうです。まあ、やってみるのが速いって感じ。SJIS <->
>EUC などのコード変換は、計算っいっても大したことないんで、速いとは思いま
>す（テキトーに言ってみる）。

計算で変換ができないのは欠点だと言う文章はよく見るので、やっ
ぱ LUT は遅いのでしょうね。128KB というサイズも MS-DOS の時
代ならヒンシュク買いそうだし。

ActivePerl の場合、perl56.dll が 648KB、strict.pm が 3KB 、
に対して文字コード表 wincode1/2.txt が 300KB だから、50% く
らいは起動が遅くなるのかな。perl も PC を立ち上げてから最初
の呼び出しと２回目の呼び出しでは体感的に起動時間が違うので、
気になる人は嫌がるかも。

テーブル参照は perl の場合、何も考えずにスクリプトレベルでや
るとハッシュになってしまうし、リストでやる場合も ord で文字
コードを得ることになるので無駄が入ってしまう。でも 'Z' を 'z
' に変換するのに 'Z'+('a'-'A') するよりは予め用意した @tolow
er のテーブルをロードして $tolower['A'] のほうが速いはず。$t
olower['a'] とかやられても場合わけの必要ないし（場合わけのコ
ストはテーブルを作るときに払っている）。

自分で LUT 方式のプログラムを作ってやるか、とも思うけど、機
能的には車輪の再発明だし、よく考えて作られた既存のプログラム
よりは遅いんじゃないかと思うとなかなか…
-- 
FZH01112@..., http://homepage1.nifty.com/dune/