実行、ソース、コンパイル、単純

虚数の２乗はマイナスです。
↑
どうなるんだろ？

はあ・・・・
この掲示板では漢字になるんですね。

なんと
高精度のほうが無料のフリーウェアで
精度の低いほうが有料のシェアウェア！

ある文字列の末尾をチェックすることはよくあります。
例えば Ｃ言語ではこんなふうに

if(ss[ii=strlen(ss)-1]=='z') ss[ii]=0；

これを素直に Perl で書くと

if(substr(＄ss,length(＄ss)-1,1) eq 'z') { chop(＄ss)； }

Ｃ言語から Perl に来た人はまず間違いなくそう書くでしょう。
ところが、この Perl の文はこうすることができます。

if(substr(＄ss,-1,1) eq 'z') { chop(＄ss)； }

このほうが、length関数を呼ばない分だけ間違いなく速いでしょうね。
憶え方としては、単純に length(＄ss) を消すことかな。
さらに

if(substr(＄ss,-1) eq 'z') { chop(＄ss)； }

と、より単純にも書けます。
また、書き方としては

chop(＄ss) if(substr(＄ss,-1) eq 'z')；

もありますが、この形式はコンパイルや実行のロジックを推し量ると少しロスがあるような気がします。
なぜなら
最終的な機械語レベルでは“実行←判定”は今のＣＰＵでは有得ないはずです。
必ず“判定→実行”になっているはずです。
だから、その流れに近い書き方の方が実行処理が軽くなるはずなんです。

　つまりは
　関数を外せるところは外したほうがいい（場合が多い）と思います。

　例えば、文字列の小文字化なんかは

＄ss=tr/A-Z/a-z/；
"\L＄ss"；

　どちらでもいいけれど、下の行のやり方のほうがシンプルだし速いと思います。

　一般的に言われていることに
“goto文を使わない”
というのがあります。

　ただし、ちょっと待って下さい。
　何故？って考えたことがありますか？

　ひとつは、ソースが理解しづらくなると言われています。
　ただし、これはソースを印刷して見た場合や、ラベルをマーク出来ないエディタを使う場合に顕著にみられる傾向で、画面で適切なエディタを使って保守するのであればそれほど毛嫌いすることはないと思います。
　かえって、無理無理 goto を避けて理解しづらいソースになっている場合もあります。

　つぎは、効率の問題ですが、これは特にいうことはないでしょう。
　機械語になった場合は、単純にブランチ（ジャンプ）命令になるだけでしょうから。

　ただし、但しです。
　そう言えるのは、Ｃ言語などの場合です。
　インタープリタで実行する Perl の場合は、実行効率が極端に悪化するということです。
　なんでも この goto 文、sed から Perl への移植のためにだけ用意したものだということらしいんです。

　したがって、Perl では

　・ goto は ラベル付きの last や next を使う。
　・ または関数化して goto を無くする。

　といったことが必要でしょう。
　例えば
　LABEL1: for(；；){
　LABEL2: for(；；){
　last LABEL1；
　next LABEL1；
　}
　}

　Perl を高速化するための注意はいろいろあると思います。

　ただ、その対策を見てみると殆どがインタープリタに対するものに思えます。
　考えてみると、とても高速だと言われているコンパイルフェーズでも対策が必要です。
　コンパイル仕様を知らないので、正確なことは言えないのですが、ただ

　・ １つのソースを多機能化させずに、出来るだけ単一機能のソースにしコンパクト化する。

ことは効果的だと思います。
　その観点からするとパッケージ化を進めることは勧められる手法かもしれません。

高速化も大切ですが、正確に動くことが前提です。
マイクロソフトの Shift-JIS は、いろいろと厄介なことをご存知ですか？
なんでこんな厄介なスタンダードが定着してしまったんでしょうね。
shift-jis の扱い方

shift-jis の時代は終わったと考えるか
shift-jis 仕様は古いと考えるか
では如何でしょうか

問題は
エディタやワープロを使っている場合、shift-jis 以外のコードを使えるかってことでしょう
過去の遺産がある場合は、諦めて shift-jis を使うしかないかと・・・