ひがさんからのありがたいお言葉

ひがさんから、ありがたいお言葉を頂戴しましたので紹介させていただきます。

＃釣り認定されちゃった。わーい。

んー、「言語の速度 != アプリの速度」という主張を示すにはあれで十分だと思いますけど。データベースやネットワークまで含めて計測したら、それこそ言語の速度に関係ない部分が増えるわけですから、先の主張がもっと強調されるだけです。そういった、明らかに言語に関係のない部分を含めなくても「言語の速度 != アプリの速度」というのがよくわかるという点で、あのベンチマークは十分意味があると思いますが、いかがでしょうか。

『テンプレートの処理の全体に対する時間の割合が出てない』とおっしゃってますけど、それこそ採用するテンプレートエンジンやアプリケーションの内容で大きく違うんだから、出してもあんまり意味ないと思いますよ。出したところで「言語の速度 != アプリの速度」は変わりませんし。それでもデータを出せというのでしたら、どれだけ意味があるかわかりませんけど、ビュー層の改善だけでアプリケーションの速度が 2 倍になった例とか、Django のテンプレートを止めることで最大 30 パーセント高速化した例とか、あとは Google の人によるこの説明を読んでください。

Unladen Swallow's benchmark suite is focused on the hot spots in major Python applications, in particular web applications. The major web applications we have surveyed have indicated that they bottleneck primarily on template systems, and hence our initial benchmark suite focuses on them:
Unladen Swallowのベンチマーク集は、主要なPythonアプリケーション、特にウェブアプリケーションのホットスポットにフォーカスしている。我々が調査した主要なウェブアプリケーションでは、主にテンプレートシステムがボトルネックであると分かった。
Google Code Archive - Long-term storage for Google Code Project Hosting.

（翻訳は日本語訳より引用、強調は筆者）

Google の見解では、テンプレートシステムがボトルネックだそうです。他にもボトルネックはあるはずですけど、わざわざ『主にテンプレートシステムがボトルネック』と言うくらいだから、けっこうなボトルネックだったのでしょう (まあ Django のテンプレートエンジンは遅いですから)。

日本を代表するアーキテクトであるひがさんには、ぜひ Google の主張を蹴散らすような調査結果を出していただき、ひいては筆者の釣りレベルを判定していただきたい所存であります。なお補足すると、eRuby より速いテンプレートエンジンを使えば、通常はそこがボトルネックになることはまずないです (eRuby より遅いとボトルネックになっている可能性はあります)。

ちなみにご自身で Web アプリを作って計測すればわかると思いますけど、言語による Web アプリケーションの速度の違いって思ったより小さいんですよ。たとえばデータベースアクセスはボトルネックのひとつですけど、JDBC と Ruby/Python 用のデータベースライブラリでは大した性能差はないです。それよりフレームワークやライブラリやアプリケーションサーバによる違いのほうがずっと大きくて、たとえば Ruby on Rails がクソ遅いのは Ruby のせいじゃなくて Ruby on Rails そのものが遅いせいだとか、JSF は Java とは思えないくらい遅いとか、mod_python がえらい高性能だったりとか、そういうのを体感すると言語の速度を競うのがすごくばからしくなります。自分が測定したときはキャッシュを使わないで計測しましたが、キャッシュを含めるとますます言語の速度が関係なくなります。ですから、キャッシュとかネットワークとかを含めない、言語のみのベンチマークのほうが、「言語の速度 != アプリの速度」がよく分かるんじゃないでしょうか。その点をふまえて考えると、あのベンチマークはきちんと意味があると思います。つうか、きちんと測定したデータを測定してない人に頭ごなしに否定されるとか意味分かんない。