プログラマyasuhoの隠れ家

某ソフトウェア企業に勤務するおじさんプログラマyasuhoです

プログラムの性能改善


先日Acrobat Readerの最新バージョンについて思ったこと。

性能改善とは


一般的にプログラムの性能改善や冗長な機能の削減は、かなり勇気のいることである。
特にバージョンアップを重ねるほどに、性能改善は難しくなってくる。


プログラムに新しい機能を追加することは、技術的にはそれほど難しくない。
現在のルートに影響を及ぼさないように注意しながら、新しいルートを加えればいいのだから。
データ構造やルーチン構造に余裕がない場合は難しいが、たいていの場合は予備の領域を取ってあるものだ。
よくできたオブジェクト構造ならば、メソッドの追加ぐらいですむかもしれない。


ある日プログラムを見直してみる。
すると、たとえ多くの機能追加が行われなかったとしても、プログラム構造に冗長な部分があったり、作りがあまりうまくないことを発見する。
ゲームで言えば、最初は越えることすら難しかったステージが、何度もプレイすることで楽にクリアできるようになる、といった感覚に近いだろうか。

現実は


だが、実際には改善するといいとは分かっていても、プログラムを書き直すのはリスクを伴う。
技術的にどうこうよりも、それがプログラムに与える影響が、機能追加よりも大きいのだ。
冗長なルーチンだから取り除こうと思っても、思わぬところで使われている機能かもしれない。
よりパフォーマンスの高いルーチンに置き換えようと思っても、何か予測できない事態が発生するかもしれない。


単純な機能追加であれば、追加された部分とある程度のテストを行えばよい。
だが、改良されたコードのテストは、機能追加よりも多くのテストが必要となることが多い。
特にそれがプログラム内での使用頻度が高い場合、改造部分が小さくても、初期バージョンと同じぐらいのテスト工数が必要になることもある。
それが製品化された時のサポート工数も増大する可能性が高い。


このような理由から、性能改善というのはなかなか難しい。
結果として、プログラムは機能追加だけが行われ、どんどん肥大化していく。
特にインタフェースの削除が難しいオペレーティングシステムにおいては、それが顕著である。
OSのみならず、アプリケーション全体に影響を及ぼす可能性を考えると、削除は難しい。

要望


そういった意味で、Adobe Readerの性能改善はすばらしいことだと思う。
もちろん実際にはアプリの初期化部分の最適化のようなので、ぼくが思っているほど大改造というわけではないのかもしれない。
しかし、このような努力がされたアプリというのは、あまり多くないような気がする。


アプリのみならず、OSも、バージョンアップされるたびに、よい速いCPU、より多くのメモリ、より多くのハードディスクを必要としていく。
パソコンの売り上げを考えると、その方がいいのかもしれない。
だが、それはソフト会社の開発工数とサポート時間を、消費者に押しつけていることにはならないのだろうか。


ソフトウェア開発にお金がかかることは理解している。
日々上がっていくパソコン性能を考えると、性能改善にコストをかけるのは、割に合わないのかもしれない。
新しい機能を実装するのに手一杯で、そんなところまでやってられない、というのが本音かもしれない。


けど、高いお金を払ってソフトを買うのだから、1ユーザとして、ソフトメーカもがんばって欲しいと思うのだ。

そこで


実際に性能改善をしないとしても、プログラム内の性能改善箇所を見つけてみるというのは、意味のあることなんじゃないかな。
開発中はそれどころじゃないと思うので、製品が出荷されて、次のバージョンの開発が始まる前に見てみる、と。
冷静な時にコードを見ると、意外なバグが見つかったりする。


出荷後にバグを見つけた時、「これ、よく今まで動いてたな」と思った人は多いはずだ。
「なんでこんな面倒なことをやってるんだろう」という部分を見つけることができる可能性も高い。
開発が佳境に入る前に、プログラムを改善する時間も取れるのではないかと思う。


とまあ、えらそうなこと言って、ぼくがちゃんと出来てるかというと、かなり怪しいんですけどね。^^;;
ま、ぼくが言うまでもなく、すでにやっているソフトメーカは多いかも。