高速なプログラミング言語が生み出す本当の価値

なんか、はてなブックマークとか見てると残念なコメントが多いよなー。『こんな比較は意味ない』とか『できることがまったく異なるテンプレートを並べて比較されても』とかいうやつ、何なの？「言語の速度 != アプリの速度」という主張を示したベンチマークなんだから別におかしくないじゃん。主旨がまるで分かってもらえてない。ネットワークやデータベースの処理まで含めて計測したら、「言語の速度 != アプリの速度」という主張がより鮮明になるだけじゃね？

反論する人があまりに残念な反論しかできないようなので、かわりに自分で「高速な言語を使う理由」を説明する (一人マッチポンプ状態じゃねーか)。

　　・　　・　　・　　・

言語が速いことによる本当の利点は、採用可能なアーキテクチャが広がることだと思う。新しいアーキテクチャを思いついたので採用したいが、スクリプト言語ではどうやっても満足な速度が出せなかったのが、Java や C のような高速な言語で実装し直したら現実的な速度に収まった、というケースは確かに存在する。これは、言語の速さのおかげで採用可能なアーキテクチャが広がることを意味していて、この点は高速な言語の大きなアドバンテージだといえる (アーキテクチャは大事だからね)。

実際の例で紹介する。またテンプレートエンジンの例で申し訳ないが、Python には Kid というテンプレートエンジンがある。これは、PHP や eRuby や Velocity のような HTML テンプレートを「汚す」タイプとは違い、HTML テンプレートをクリーンに保てることが特徴である。仕組みとしてはこんな感じ：

• HTML テンプレートを読み込んで DOM ツリーを作成
• その DOM ツリーを操作
• DOM ツリーを HTML へ変換

この仕組みの利点としては、HTML テンプレートが汚されないのでデザイナにとって優しく協業しやすいことと、ほぼ完全な HTML エスケープが行える (エスケープし忘れが発生しない) ことである。この利点は非常に大きい。

ただ、動作速度は極めて遅い。どのくらい遅いかは前のグラフのいちばん下を見てもらえばわかるけど、速いテンプレートエンジンと比べてだいたい 1/60 ぐらいの速度。これは「DOM ツリーを作成・操作・HTML へ変換」という作業を毎回やっているせい (そりゃ遅いよね)。このくらい遅いと、実行時間の大部分がテンプレートエンジンで費やされてしまう。Kid を改良した Genshi というのもあるけど、これもやっぱりすごく遅い。この手のタイプが遅くなるのは、アーキテクチャ上仕方ない。

ところで、これとよく似た Java 用のテンプレートエンジンに XMLC というのがある。というかこっちの方が本家で、Kid のほうがあとから真似たんだけど、どちらも「DOM ツリーを作成・操作・HTML へ変換」という基本アーキテクチャは同じである。

ただ Kid と違って、XMLC のパフォーマンスは良好である。たしか「実践J2EEシステムデザイン」にベンチマークが載ってたと思うんだけど、それによると Velocity より速いらしい。その理由は、XMLC ではプレゼンテーションロジックを Java で記述し、変な独自言語やインタプリタを導入していないため。つまり Velocity と違って、静的言語である Java のよさとパフォーマンスをそのまま享受できるわけだ。もちろん本自体が昔の本なので現在ベンチマークをとるとどうなるかはわからないけど、独自言語の動的なインタプリタを使う Velocity よりは、アーキテクチャ的には不利でも素直に Java をそのまま使った XMLC のほうが速いというのは納得できる。

Kid も XMLC も基本となるアーキテクチャはよく似ており、どちらもデザイナに優しいテンプレートエンジンである。ただ動作速度的には不利なアーキテクチャであることも事実であり、実際 Kid のパフォーマンスはすごく悪い。しかし Java をそのまま使う XMLC は、速度的に不利なアーキテクチャでも実用的な速度で動作する。

この点こそが、高速な言語を使う利点だと思う。DOM ツリーを作らないアーキテクチャなら Python でも非常に高速なテンプレートエンジンを作ることは可能。でもデザイナーに優しいテンプレートエンジンを作りたいから DOM ツリーを使うアーキテクチャにしたいと思ったとき、pure Python では非常に遅いテンプレートエンジンしかできない。しかし Java なら速度的に不利なアーキテクチャでも現実的な速度で動かせる可能性が高い。つまり高速な言語のほうが利用可能なアーキテクチャの幅が広がるというわけ。

なおデザイナーに優しいテンプレートエンジンを作るには必ずしも DOM を作る必要はない。ちょっと考えればわかるけど、動的に操作したい要素は HTML テンプレートの中の一部だけなんだから、そこだけ操作できるようにしてやればよいわけで、ページ全体を DOM に変換して操作するのは無駄すぎる。その点でいうと、Kid も XMLC もアーキテクチャを改良する余地は多いにある。

今日の結論： 高速な言語のほうが利用可能なアーキテクチャの幅が広がる。

＃ちょっとタグをつけすぎたかも。ごめんなさい。