2009年12月アーカイブ

iPhoneのおかげでObjective-Cがかなりメジャーな言語となった。それはうれしいことだ。わたしはObjective-Cが好きで、それは元を正せばSmalltalkが好きだというところに通じる。ただObjective-Cはメリットの裏表で実行時のパフォーマンスに難点がある。いや、それさえも回避可能ではあるけど、記述の利便性が損なわれたり、よく知ってないとできないことも多い。

例えばメッセージ式で型推定は行われないので、毎回素直にセレクタに対応するメソッドを探してから呼び出す。もちろんキャッシュの仕組みなんかはあるのだけど、直接コールするよりは何倍も重い処理になっている。以前３Ｄエンジンを実装したとき、ステート管理を素直にメッセージ式で呼び出すいわゆるObjective-Cのクラスで実装したら劇的に遅くなって愕然としたことがある。メッセージ式は大量に呼び出す必要があるとき、とくに回数の多いループの中なんかは要注意だ。

Objective-C 2.0で実現されたプロパティも困った問題を引き起こすことがある。アクセス方法がC/C++でなじみのドットアクセスなので、ついついその感覚で使ってしまうのだろうけど、パフォーマンスに影響あるところで

@property (nonatomic) Vector *position;

...

object.position.x = 100;
object.position.y = 100;
object.position.z = 0;

というような記述を見てくらくらとしたことがある。これは、つまり

[[object position] setX:100];
[[object position] setY:100];
[[object position] setZ:0];

だと考えれば、どれだけのコストがかかってるか分かるのだけど、簡便な記述がそれを見えにくくしている。

ただ、Objective-Cを使う人口が増えるということは、コンパイラに手を入れる人間の数も増えるということなので、近い将来にパフォーマンスのかなりの部分をコンパイラが面倒を見てくれるようになるかもしれない。

さて、今回も枕が長くなったが、Objective-Cの（実装内容を見れば実は普通のＣの機能なのだけど）Toll-Free-Bridgeという仕組みを調べて行くうちに、いろいろとパズル的にC++側から見れば純粋なC++なクラス、Objective-C側から見れば純粋なObjective-Cの実装というのができないかと考えてみたというのが本題である。

iPhoneにGoodReaderというPDFを高速に表示できるアプリがある。PDF以外も対応しているのだけど、試してみたことがないのでその機能がどれぐらいかと言うことは分からない。ただ、PDFの表示速度だけでこのソフトを選んでも良いんじゃないかと思わせるぐらい、速い。

iPhoneというか、OSXはもともとネイティブにPDFに対応している。その前の歴史としてNeXT Stepの表示システムがdisplay postscriptだったという由来があるのだけど、歴史は置いておいて、その流れをくむiPhoneのアプリケーションフレームワークであるCocoa TouchもPDFを投げれば表示してくれるような仕組みがある。ただし遅い。

GoodReaderはPDFをレンダリングするコードを独自に（オリジナルかどうかは分からないけど）実装して高速化しているようだ。