プログラムの高速化はプログラマにとって永遠の課題です。しかし，そこには知られざる暗黒面が隠れています。そもそも高速化に意味があるのかを調べなければなりません。次に，どの部分をどの程度高速化するのかが重要です。アルゴリズムの効率にも目配りが必要です。

　コンピュータの処理速度は驚くべき勢いで向上しています。現在私たちが使っているパソコンは一昔前のスーパーコンピュータをしのぐ性能を備えていますし，半世紀前に登場したばかりの計算機と比較すると数十万倍の性能に相当します。

　このように高速なコンピュータを持っているにもかかわらず，人間の欲望は限りがないものです。プログラムの実行速度はプログラマにとっての永遠の課題のようです。プログラムを高速化していると，「そんなに急いでどこに行く」という気になることもあります。

　今回は，プログラムの高速化にまつわるさまざまな「秘密」と「限界」，そして「戦略」について解説しましょう。

「速いことはよいこと」なのか

　プログラムの高速化（パフォーマンス・チューニング）というテーマを考える際，一歩引く必要があります。プログラムの高速化がいつも望ましいとは限りません。他のさまざまな要素と同様，パフォーマンスにもトレードオフが存在します。常に速度が最も重要ならば，常に最高速のマシンを用意しなければなりません。さらに，最も高速なプログラムを記述できる低水準言語（例えばアセンブリ言語）をプログラミングに使用する必要があるかもしれません。

　しかし，速度を最優先することが良いとは限りません。予算，開発効率，開発期間などの制約の中，高速化が本当に割に合う場合にだけ，高速化のコストを払うべきです。

　例えば，100Mバイトのデータを処理するプログラムをRubyを用いて記述したとします。コーディングに30分かかり，実行に2時間かかったとしましょう。時間の合計は2時間30分です。同じ処理を30分で終えようとして，プログラムをCで記述した場合，8時間かかったとしたらどうでしょうか。実行時間は短くなりましたが，合計は8時間30分です。どちらがおトクかは言うまでもないでしょう。

　しかし，この処理を毎日繰り返し実行するとなれば，結果が出るまでに待つ時間が2時間と30分では全然違いますから，C言語で8時間かけて開発する意味が出てくるでしょう。

　繰り返しになりますが，パフォーマンスはトレードオフです。通常は，必要な処理が必要な時間内に計算できればそれで十分です。制約も何も考えずに「とにかく速く」と高速化に飛び付くのはあまり賢明とは思えません。

高速化の楽しみと効率

　プログラマにとって，プログラムを高速化する行為そのものが知的なチャレンジです。どこが遅いのかを探し出し，問題点を推測し，改善することでプログラムの実行が次第に速くなっていきます。ある種のパズルを解くような「楽しさ」があります。改良の結果が実行時間というはっきりとした数字で現れます。パフォーマンス・チューニングの達成感はプログラミングの中でも最も充実した部分だと言えるかもしれません。

　それはそれで結構なことですが，実務においては達成感だけでは済みません。仮に私のノート・パソコンの値段が20万円で，3年間使えるとすると，1秒当たりの値段に換算すると0.00211円にしかなりません。私の時給が仮に（実際よりもかなり低い数字ですが）760円だとします。実行時間を10秒速くするために1時間使ったとすると，その1時間を取り返すために，高速化したプログラムをよほど繰り返し実行しなければならないでしょう。単純計算でも3万6000回近く繰り返さないと760円を取り返せません。

　趣味のプログラミングならともかく，実務ではパフォーマンス・チューニングに取り掛かる前に，本当に高速化が必要なのかを確認しなければなりません。どの程度高速化する必要があるのかを前もって見積もっておく必要があるでしょう。