私がこの業界に入って15年ほど経つ。その間CPUの性能は3倍どころか100倍以上になり、メモリは数万倍に増えた。ユーザが一昔前とは比べ物にならないくらいに高度なものを要求するようになったことを考慮しても十分な向上だ。
では楽になったのだろうか？確かにガベージコレクションは象牙の塔から飛び出して実用に足るようになり、組み込みなど一部の世界を除けばメモリのことを心配する必要はなくなった。OOPは標準装備となり、OOPの余分なちょっとしたレイヤーを遅いから嫌だといってCやアセンブラにこだわっていた人種は絶滅した。
しかしおかしなことにプログラマは今だにパフォーマンスに悩まされ続けているのだ。なぜか？
CPUは早くなったがIOアクセスやプロセス間通信はそれほど早くなっていないからである。その最たるものがデータベースアクセスだ。この本などを読めばCPUやメモリ性能だけが決定的な差ではないのだということを教えられる (by シャア)。
データベースアクセスのパフォーマンスを向上させるには実にさまざまな方法があり前述の本などに詳しいが、ドダイでの取り組みを紹介しよう。
例えばStaffというテーブルを考える。カラムにname,email,passwordと所属部をあらわすためににdivision_idを考える。別途Departmentテーブルを作り実際の部署名などを保存する。Staffのリストを表示したい場合、通常であればStaffとDepartmentをJOINすることになるだろう。しかしこの方法にはさまざまな欠点がある。
ドダイではキャッシュを使ってこの問題に対処することができる。この場合であればStaffテーブルに対応したTblStaffというクラスが自動生成される。そしてTblStaff.division_idをTblDepartmentにマッチングさせるためにキャッシュを利用するのである。そしてそれを行うメソッドが自動的に実装される。
キャッシュはグローバルエリアに置かれ、Departmentテーブル全体がキャッシュされる。したがって頻繁に変更されたり、巨大なテーブルである場合にはこの方法は適さない。逆に言えばDepartmentのよなマスター系と呼ばれるテーブルの場合にはこの手法が最適なのだ。
Webアプリケーションの場合はさらに都合がいい。誰かが一回キャッシュを作成すればその後は高速なHashアクセスしか起きないので必要に応じて余分なSQLを発行する必要もなく高速にアクセスできる。
OOPとしての利点は甚だしい。Staffの持つべきメソッドを自然に一箇所に記述できるしC#コンパイラの方チェック機構や文法を利用できるのも利点だ。SQLに直接書いてしまうと単純な名前チェックさえ実行時にしか行われなくなるのだ。
キャッシュだけでパフォーマンスが解決するわけではない。キャッシュのクリアタイミングや分散サーバーのときなど問題も多い。しかし私にはOOP的にスッキリ記述できるという点は捨てがたい利点に見えるのだ。