正規表現、変数、処理、アドレス

foaf.rdfのなかにはﾒｰﾙｱﾄﾞﾚｽを書かなくてはいけないのですか

　FOAF に記載するメールアドレスは、メールの送受信のためのものではありません。
　そのアドレスを流用して、個人個人を区別するために使っています。
　つまり、個人個人が区別できればそれでいいので、通常メールアドレスを暗号に変換して使っているようです。
　この暗号は、メールアドレスから暗号へは変換できますが、逆の、暗号からメールアドレスへは変換出来ないようです。
　＜foaf:mbox＞mailto:メールアドレス・・・
としないで
　＜foaf:mbox_sha１sum＞暗号・・・
とします。
このHPが参考になります。

メールアドレスを暗号化して個人識別に使うってのはアイデアですよね。
暗号化してしまえば悪用される危険性も少なくなると思うし。

perl講座というサイトを見つけました。
その、第９章 正規表現、というところでこんな記述を見つけました。

・if ＄method =~ /^GET＄/; # 遅い
　if ＄method eq "GET"; # 高速
＊）これは納得。
　でもこのような書き方はまず誰もしない。

・＄str = "We've accomplished";
　print ＄str =~ /^.{６}(.{１２})/, "\n"; # 遅い
＊）これも常識的に有り得ない書き方。

・ マッチ変数 ＄& ＄` ＄' ＄+ を使うとプログラム内のすべての正規表現の処理が遅くなる
＊）これは初耳です。
　確かに別ライブラリ化という線はありそうですが、しかしライブラリはＣ言語で書かれた高速モジュールのはずです。
　足を引っ張るのはバックトラックであり、＄& などの変数値設定はスズメの涙だと思うのですが？
　うーん？

　この No.９４ の、マッチ変数について考えてみました。
　おそらく、これを書かれた方は実際に計測されたのでしょうが、多分 for などでかなりの量のデータ処理を測られたのだと思います。
　つまり、コンパイル時間を無視した実行時間の評価に偏っているように思えます。

　コンパイル時間と実行時間とに分けて考えた場合
　＄& などの処理を正規表現を使わないで複数行の index substr split 等の記述にした場合は、実行時間もさることながらコンパイル時間が増大しそうです。
　それにコンパイラの精度にもよりますが、複数の文章よりも単文のほうがオプティマイズは楽でしょう。
　つまり、for や while で膨大なデータ処理をやるのでなければ ＄& 等を積極的に使ったほうが効果的だと私は思うのです。
　とくに cgi ではその傾向が強く、出来るだけ ＄& ＄` ＄' ＄ を使い単純でコンパクトなソースにするべきだと思います。

　この方のマッチ変数の考え方に関しては、もう一つ疑問があります。
　同じように、その正規表現を含む文の外にもスコープをもっている ＄１ ＄２ ＄３ ･･･ も同じ扱いで遅くなるのでしょうか？
　もしそうであれば、Perl の言語としての魅力は半減してしまいます。

正規表現〔Perl講座-smart〕

　No.９４ と ９５ のサイトではこうまとめているようです。

＞＞
正規表現を速くするコツ
　* 正規表現内に変数がある場合、/o オプションを使って１度だけ評価するように指示する
　* マッチ変数を使わない（＄` ＄& ＄'）
　* 選択パターン | の使用を避ける
　/a|b|c/ の代わりに /[abc]/ が使えます。
　* メモリを使わないカッコ(?:…)によって高速化（多少）
　/(?:\w )/ など

　整理してみましょう。
　べつにこの方の見解がどうこうというのではないのです。
　一般的に言われていることですし・・・

　マッチ変数については No.９４ ９５ で考察しました。
　私としてはどんどん使おう。です。

　o オプションですが、
　まず、『正規表現内に変数がある場合』というのが誤解の元です。
　普通、『g 以外では o は使わない』し『g を指定したとき o を指定するしないは明確に目的がある』ということです。
　単に速度アップするために o を使えというのは無謀です。
　誤動作の元になります。

　例えば文章から単語を明確に切り出す場合は
　s/(\w )/＜＄１＞/g
　として
　＜Perl＞ ＜is＞ ＜nice＞ ＜for＞ ＜cgi＞
　といった結果を得ます。

　言葉使いを統一する場合は
　s/(coll?or)/＄１/goi
　として
　First color is red, Secont color is blue.
　と整形します。
　ただし、この場合は普通
　s/coll?or/color/gi
　とすると思います。
　つまり o オプションの使い道はかなり特殊な場合になります。
　＄１ と go オプションの両方を指定するのはどんな場合ですか？
　ちょっと思いつかないでしょ？

　したがって私としては o オプションは指定するな。です。

　つぎは
＞＞
正規表現を速くするコツ
　* 選択パターン | の使用を避ける
　/a|b|c/ の代わりに /[abc]/ が使えます。

　これはもう当たり前のことで、ほとんどの方がご存知だと思います。
　ただこれも、前に書いたように、正規表現の処理ライブラリがＣ言語などで作られていることを考えると、神経質になる必要はないと思います。

　つぎは
＞＞
正規表現を速くするコツ
　* メモリを使わないカッコ(?:…)によって（少し）高速化
　/(?:\w )/ など

　これは実はかなり矛盾しているように思えます。
　つまり、＄１ という変数に値を設定することが少し速くなるというのです。
　しかし、No. ９４ では
　マッチ変数 ＄& ＄` ＄' ＄ を使うとプログラム内のすべての正規表現の処理が遅くなる
　といっているんです。

　もともと・・・
　外部にたいしてスコープをもつ変数は珍しくもないですし、コンパイル終了時点でそれらの変数はアドレスは解決されているはずです。
　さらにライブラリはＣ言語での高速処理が行われている。

　いったい何故、＄１ ＄& ＄` ＄' ＄ を使うと遅くなるというのか根拠が解らないんです。

　No.８２ 〜 ８５、８８、８９ が高速化のポイントでしょう。とくに cgi としては。
　そして、正規表現の高速化ということに関していえば、バックトラックを防ぐということが一番大事だと思います。
　それ以外の 正規表現処理の高速化手法は、どうも根拠が薄いようなきがします。

パールの特徴を思い出してみよう。
文章処理です。
正規表現を使わなければ意味ないし、インタプリタもそれは十分に理解しているでしょう。