コンパイル、関数、効果、スコープ

Error:You cannot use trackback tool from local PC.
FC２BLOG：FC２ブログでよく見かける（というよりも私の場合は必ずでる）エラーです。
ちょっと分かったことがありました・・・
FC2ブログのトラックバック問題

だいたい結論がでました。
つまり、Perlの高速化は

・出来る限りステップ数（行数）を減らす。
　機能をまとめつつ最大の効果を考えるなら、プリプロセッサー使用が効果的。
＞効果：コンパイル時間の短縮。
＞効果：インタープリターのフィッチが減り、実行速度が吟味されたPerl本体ライブラリが走る。

・goto文、return文をダミィの for(;;) lastブロック へ。
＞効果：コンパイルとインタープリターの解析処理軽減。

・正規表現では ＋? *? を入れる。
＞効果：バックトラックでのループ防止。

mod perl もいいとは思うが、レンタルサーバー環境なども考えるといまひとつ・・・
やはり究極の高速化は、プリプロセッサーで贅肉落しかと。

細かい注意としてはそういうことでしょう。
ただし、問題は「実行時間の９割はコンパイルが占める」という点です。

一般的に Perl/cgi では、Apache などの webサーバーが、cgiプログラムを fork し実行します。
問題は、この fork 後のコンパイル時間が凄く長いことです。
かなり神経質に不要なライブラリのロードを避けても、cgi 実行時間の約９割は Perl のコンパイル時間です。
そうなんです。もうお気付きだと思うんですが「お、これは便利なライブラリーだな」と気軽に use や require するのはちょっと待って下さい。
多くの汎用ライブラリーは、その名のごとく汎用なんです。
つまり、「あれも出来る、これも出来る」で、かなりの量があるんです。
ライブラリーも吟味しないと！
なんせ、実行時間の約９割コンパイル時間！

サーバーを好きな環境に出来るのであれば（レンタルでなければ）mod_fastcgi、mod_fcgid、mod_perl、mod_perl２、mod_speedycgi が有効です。
Apache に組込むのが嫌なら、SpeedyCGI。
これらはどれも、一度コンパイルしたプロセスを常駐させるというものです。

特に、mod_perl は「Apache と Perl を一体化」するので最も効果的ですが、移植性は悪くなります。
Movable Type などでは特に注意が必要なようです。

つまり、Perl の高速化の極意は！
ライブラリーを含め、ソースを小さくする努力をする！
実行時間の９割はコンパイル時間。お忘れなく。

コンパイルはソース全体を解析します。
だから、その解析時間はソースの大きさの２乗か３乗的に増加するはすです。
その後は一つづつ順にインタープリートするだけ・・・

とてもいいヒントでした！
有り難う御座いました。

実行時間の９割がコンパイルだとすると
・そのコンパイルフェーズをスムーズに流させることと
ですよね。

たしかに・・・
考えて見れば、モジュール解析は、その大きさの何乗かくらいの比率で時間がかかるでしょうし、それによく言われる goto文 の効率が恐ろしく悪いことも理解できます。
ポイントは『何乗かの比率・・・』ですね。

とすると、まずモジュール全体を小さくする。
スイスアーミーナイフのような十徳ナイフを作らずに
ナイフはナイフだけ、鋏は鋏、ドライバーはドライバー、といったふうにして必要なものだけを取り込むことですね。

次にスコープの問題です。
Ｃ言語なんかの場合は、関数呼び出しのオーバーヘッドを嫌う場合は“開いたサブルーチン”で直接展開しますが、これはまずい。
実行時間の占める割合は１割でしかない。
出来るだけ小さな関数にして解析スコープを狭くする。

さらに変数もグローバルをやめて引数渡しにして、関数を排他的にまとめてしまう。
それを明示的に my 宣言でコンパイラーに教えてやる。
必然的に strict を宣言する。

さらに特定条件下でのみ必要な関数は require にしてしまう。

こんなところでどうでしょう。
かなりコンパイラに優しいソースになるんじゃないでしょうか？

なるほど！
プログラマーの頭には「実行速度を上げる」という意識は常にあります。
「コンパイラーに優しい」という意識は全くありません。
コペルニクス的に考え方を１８０度変えないとダメなんですね。
目からウロコでした。

なるほど、スコープですか。

ちょっと考えさせられたのは、local と my の変数宣言です。
local は最初から仕様化されていました。my は追加仕様です。

よく考えると、local 変数を持った関数は“スコープ的に独立”できないような気がします。
この観点では、自動変数 my なら何も問題ないんです。

our my で明確にスコープ宣言をする効果は大きいと思います。
our は使わないほうが効果的ですから、“local を my に変える”ことになりますが。

ここ２日ばかり xrea.com サーバーが重くなっていませんか？
コアサーバーへの勧誘ねらい？じゃないよね？

＞＞「実行時間の９割はコンパイルが占める」

それはそうかもしれません。
９割というのが実測された結果なのか、およその感なのかはわかりませんが、確かに多くの負担のかかる処理です。

＞＞『何乗かの比率・・・』
ちょっと違うと思うのですが、感覚的にはそういう感じかもしれません。

そこを除けば、No. ８４【Perlを高速化する】の方法で効果をあげることが出来ると思います。
というか、方法はそれしかないと思います。

Perl に限らず、インタープリターでは“ハッシュテーブル”と“スコープ”を意識すると、抜群に効果があります。
インタープリターは

１ コンパイル
１．１ 関数解析
　・ 構文解析
　・ 字句解析
１．２ アドレス解決
２．実行

という構成で、まず
・ ソースから字句解析で変数のハッシュテーブルを作りながら、構文を解析し中間命令を吐き出します。
・ これを関数（やブロック）単位に一つずつ処理します。
・ 中間命令を全て作成し終わってから、そのアドレスを解決します。
・ そして中間命令を実行します。

言えることは

・ ある関数やブロックや文が、実行に必要か不要かは、中間命令を全て作成しないと判りません。
　場合によっては、中間命令を実行してみないと判らない場合もあります。
　つまり、「必要な関数も不要な関数も全てコンパイルされる」ことです。
　不要な（実行されない）関数は、別ソースにするべきです。

・ 変数などのハッシュテーブルは、スコープ単位に作成され、ネストの深いスコープ順に１本にリストされます。
　つまり、スコープが小さいことと、スコープ外のハッシュが無いことが効果的です。
　関数は小さくしグローバル変数を持たないことと、関数が大きくなる場合はブロックを切ることです。

それと、変数に my を付けて明示的にスコープを与えることで、コンパイラーに無駄な労力をかけないこと。