このプログラムは巨大な画像データを扱っています。したがって、莫大なメモリを消費します。 一応、単純な１次元圧縮をしていますが、それでも大変なメモリを使い切っています。
ysize = 50000, line_max = 500で計算してみましょう。ELEMENT_DATA型は４バイトです。１ラ インについて、これがline_max個並ぶので、２KB/ラインということになります。全部で50000ライ ンあるのだから、
2KB×50000 = 100MBということになります。たった１枚の絵のデータが100MBにもなるのです。元のプログラムは、100 MBものメモリをビット単位でゼロクリアしていたのです。考えただけでもぞっとするではありませ んか。
画像データに限りませんが、大きなデータを扱うときには、データ構造を注意して決めなければ なりません。図１４−１のデータ構造には、信じ難いほどの欠陥があります。いままで、とても下 手な、信じ難いようなプログラムを多数紹介してきましたが、そんなものとは比較にならない「超 致命的な欠陥」があるのです。それは何でしょうか。
ということは、最も複雑なラインに合わせて、単純なラインでも要素がいっぱい確保されるので す。したがって、たとえ100MBのメモリを確保しても、その過半数は未使用のままということです。 各ライン毎に、必要なだけの領域を確保すれば、全体で10MBとか20MBのメモリで済み、全データが オンメモリで動作するかも知れないのです。
グラフィック関係のソフトウェアは、とにかく速度が重要なのです。巨大なメモリを使い、CPU をガンガン使いまくります。だから、データはオンメモリにないと、直ぐにスワップが始り、ディ スクだけがカタカタと音を立て続けるが、いつまでたっても処理が終わらなくなります。
各ライン毎に、必要なデータ領域を確保すればよいだけなのです。しかし、このソフトウェアの 場合、このデータ構造に従って10万行以上のコーディングがされていました。このデータ構造は、 プログラム全体のベースになるような部分なので、ここを変更すると、膨大な量の変更が発生しま す。そういう訳で、このプログラムは頑固にも、固定長データ型式のままで、巨大なメモリを確保 しながら（決して使っているのではありませんよ！）、今も動作し続け、バージョンアップが続い ています。
データ構造は開発の初期に決めるので、その決定は慎重にならざるを得ないのです。そのフェー ズに、一言相談していてくれたなら、もっとちゃんとした、柔軟なデータ構造にしたのにと思って しまいます。
このデータ構造は、いずれ変更せざるを得ないと思いますが、１カ月以上もの間、全ての開発作 業がストップし、変更後もトラブルが発生しそうです。後から、システムの根幹部分の変更という ことを考えると、担当者の苦悩は大変なものだと思います。
６回にわたった長大でDirtyなプログラムは、Ｃのdirtyさ以上にデータ構造がdirtyだったので す。致命的なまでにdirtyだったのです。初期に、専門家によるコンサルテーションさえ行なわれ てさえいたら、決してこんなことにはならなかったでしょう。
プログラムのテクニック以上に、データ構造の決定が重要なことをしっかり認識してください。 下手な関数など棄てて書き直せば済みます。でも、データ構造の決定を間違えたら、プログラム全 体の書き直しに発展してしまいます。システム販売後だと、客先で作ったデータのフォーマット変 換もする破目になります。Ｃ言語の小技より、データ構造の設計や、プログラム全体の構成とか方 式のようなものの方が遥かに重要なのです。
Ｃのプログラムは、データなどをハンドリングするための、ただの道具に過ぎません。プログラ ムが扱う対象の方にこそ注力しましょう。