タダでソフト開発の生産性と品質を上げる方法（10）：プログラムの実行速度を瞬時に測定する「gprof」：山浦恒央の“くみこみ”な話（100）（1/3 ページ）

ついに連載第100回を迎えた「山浦恒央の“くみこみ”な話」。今回の「タダでソフト開発の生産性と品質を上げる方法」の第10回では、プログラムの実行速度を瞬時に測定する「gprof」を紹介します。

[山浦恒央 東海大学 大学院 組込み技術研究科 非常勤講師（工学博士），MONOist]

1．はじめに

　世の中には、効果の非常に大きい開発支援するツールが少なくありませんが、多忙なエンジニアの目にとまることは多くありません。本シリーズでは、そんなエンジニアの手助けをする「無料の簡単強力ツール」を紹介しています。このシリーズが開発手法を見直すきっかけになればと思います。今回は、プログラムの実行速度を計測する「gprof」というツールです。

2．実行速度にまつわる過去と現在

　過去40年間を振り返ると、ハードウェアの性能は革命的に進歩しました。CPUの速度は倍々に増加し、メモリは安価で大容量化し、あらゆる製品にコンピュータが組み込まれています。40年前はメモリは非常に高価で、かつ、容量は数Kビット程度でした。そのため、当時のプログラマーは、メモリ占有量が少なく、実行速度が早いプログラムを追求し、職人技、芸術、奇術に走りました^※1）。

※1）メモリ占有量が少なく、実行速度が速いプログラムを追求した結果、いわゆる「スパゲティ構造」のプログラムがほとんどでした。現在のモジュールは、入り口が1つ、出口も1つ、プログラムの流れを構成するのは、「上から下への順次実行」「if-then-elseによる判定」「繰り返し」「サブルーティン呼出し」の4つだけというのが基本です。これが「構造化されたモジュール」で、現在の高級プログラミング言語を使う限り、必ず、何が何でも、絶対に、強制的に「構造化モジュール」になります。

　今から40年前は、搭載メモリが少ないため、プログラム全体がメモリに入りきらず、また、小型機では仮想記憶も一般的ではなかったため、「貧乏人の仮想記憶」と言われた「オーバレイ」を使い、プログラマーが自分で仮想記憶を実装していました。すなわち、ハードウェアの制限が、ソフトウェアの設計法やモジュール構造を捻じ曲げていたのです。今では想像できないと思いますが。

※写真はイメージです

　また40年前は、アセンブラ全盛期で、設計は何でもあり。1つのモジュールに入り口が幾つもあり、ひどいと「キッチンの窓」から入って「トイレの窓」から出るモジュールも当たり前でした。もっとすさまじいのが、「命令語の動的な書き替え」です。例えば、メモリ中にある命令語、「LR R11, sutudent_01 （student_01の内容をレジスタ11にロードする）」の「LR」を2回目の実行では自分で「SR」に書き換え、「SR R11, sutudent_01 （レジスタ11の内容をstudent_01へストアする）」に無理やり変更する「荒技」です。2回目にこの命令語を実行する時は、「SR」になっているため、ソースコードの字面のままではありません。こうなると、「技術」ではなく「奇術」ですね。

　可哀そうなのは、そんなプログラムを保守せねばならない現在のプログラマーです。そんな奇術的、職人芸的プログラムを若手エンジニアが改造しなければならない場合が少なくありません。さらに、若手エンジニアからみると、旧石器時代のプログラム言語（アセンブラ、フォートラン、コボル）を読み解く必要があり、泥沼に陥ります。こうなると、「ヒエログリフ文字の解読」ですね。

　現在は、手帳よりも小さい携帯電話機にGビット単位の容量のメモリが入っています。高性能になった分、早いプログラムより、誰でも理解しやすいプログラムが重要となりました^※2）。

　そんな時代でも、リアルタイム性が高いソフトウェアでは、「10ms以内で動作すること」などの実行速度を仕様書で記載し、エンジニアは常に実行速度を気にして開発します。

　実行速度の難しい点は、プログラムを実機に入れないと、本当に応答性能が範囲内かどうか分からないことです。実機では、単体のプログラムと異なり、「装置の物理的な無駄時間」や「通信の遅れ」が原因で想定外のバグが現れます。バグの原因を突き詰めると、「処理負荷のせいだった」ことも少なくありません。

　上記のリスクを減らすため、実機で検証する前、少なくともソフトウェア上での実行速度を把握し、トラブル時に迅速に対応する用意をすべきでしょう。特に、実行速度が多大な影響を与える「ボトルネック」を見つけることが重要です。通常、ボトルネックの検出は熟練エンジニアがソースコードを追って見つけますが、ツールがあると誰でも検出可能です。今回は、ボトルネックの検出に効果がある、プログラムの実行速度計測ツールを紹介します。

※2）もちろん、プログラムが早いに越したことはありません。携帯電話機、ゲーム機、プリンタなどのどんなソフトウェアでも、実行速度は重要な要素ですが、分かりやすさや、保守の容易性を犠牲にしてまで、性能を上げることは「悪」と筆者は思っています。組み込み系のプログラミングでは、「性能vs.理解容易性」は、永遠の課題でしょう。この2つの間で「振子」はいつも揺れています。