ラリー・ウォールの言葉に、「プログラマーの三大美徳は、怠惰・短気・傲慢である」と言うものがあります。
怠惰については以前に考えてみましたが、今回は「短気」について考えてみます。
「短気」の意味
もちろん、この「短気」も普通の意味ではなく、プログラムの動作が遅いことを許容できない、という意味合いです。人間関係については短期になっても得なことはありません。
遅いことによる問題
遅いことそれ自体による問題
セキュリティ上の要請があって「遅い方がいい」プログラムもまれに存在します1し、ユーザーインターフェースのプログラムの場合は「ユーザーの反応速度に合わせる」必要がありますが、そういう場面でない場合、動作が遅いことに対してはデメリットしかありません。Amazonによれば、サイト速度が0.1秒遅くなれば、売上は1%低下するとされています。
負荷の問題
通信などの待ち時間が多くて遅くなっているプログラムなら別ですが、そうでないプログラムの場合、何かしらの処理を行うことに時間を取られているわけです。CPUバインドな処理にしろI/Oバウンドな処理にしろ、何かしらの処理を行う以上は電力も消費します（モバイルアプリの場合は特に考慮が必要となります）。また、サーバ処理などで処理を多並列に行う場合、1つのサーバで捌ける量が減ってしまうので、サーバを増やすなどコストもかさんでしまうこととなります。
バグ・不具合の兆候
フレームワーク段階で問題なく速度が出ている状況で、ある箇所だけ極端に遅いとなれば、それはそこのプログラム上の問題が疑われることになります。また、ふだん十分な速度が出ているのにあるときだけ遅くなった場合も、何かしらの不具合を示唆するものとなります。
ただ、元から遅ければそういった異常のサインに気づく余地もないので、何もなければ充分な速度が出るようにしておく必要があります。
注力すべき点
「アルゴリズムとデータ構造」という本もありますが、高速化にあたってはこの2つの見直しが最重要ポイントだと考えます。アルゴリズムを見直せば、計算量のオーダーから変わってしまうこともありますし、データの保管先はレジスタ＞キャッシュ＞メモリ＞ディスク＞ネットワークというように、選び間違えればCPU時間とは比較にならないほどの時間を消費するものなので、適切な箇所に適切なデータを置くことで大幅な高速化が望めます。
コードのちょっとした書き方を変えたところで、数倍変われば御の字といったところです。たとえばWebサーバで動くシステムの場合、まずWeb自体の通信時間が速くて数ミリ秒、遅ければ100ミリ秒単位でかかってしまいます。そんな環境下で1マイクロ秒高速化できても、ほとんど意味がありません。
-
総当たり攻撃を避けるために、パスワードのハッシュ化をわざと長時間かかる関数で行うなど ↩