JSPが遅い理由をJava屋さんはまるでわかってないらしい

なんかVelocityもJSPもスクリプト言語より遅いという事実は、Java屋さんはあんまり知らなかったみたいだね。しかも、遅い原因の考察が的外ればかりで笑ってしまう。
「Javaの文字列操作は遅いから」とか「UTF-16の変換に時間がかかるから」とか、そんなのまるで関係ないですから。Javaの文字列操作は十分速いし、UTF-16の変換も主要因ではない。
＃つうかさ、「Javaの文字列操作は遅い」とか、Javaに対して失礼だろ。

VeocityやJSPが遅いのは、単に動的な独自言語を導入したから。はっきりいって、これはアーキテクチャ上の間違った選択。せっかくJavaが静的であるのにその特性を利用せず、わざわざ動的言語を導入しているのだから、何考えてんだろうと思う。いつもJava屋さんが主張しているような、「コンパイル時にエラーを発見できる」「IDEでの補完が効きやすい」「リファクタリングがしやすい」「動作が高速」といった利点は、動的言語を使うVelocityやJSPでは享受できないんだから、静的言語のメリットを説く立場ならやっぱり間違った選択だと思うよ。
あと、動的言語を導入している点では同じなのにJSPがVelocityより遅いのは、単にJasperのコンパイラがおバカなだけ。1行ずつappendしてるんだから、そりゃ遅いよね (たとえるなら「Ruby 1.8.6までのERBと1.8.7でのERBの差」と言えばわかるだろうか)。そんなことも分かってないのに的外れなコメントする人が多すぎ。

NOV1975 prog そりゃあアセンブラで真の目的にのみフォーカスして書いたアプリが最速なわけで。目的と手段とコストの問題だから、解決のアプローチはスケールアップでもよいのだよ。 2010/04/30

はてなブックマーク - プログラミング言語の速度とアプリケーションの速度がいかに関係ないかがわかるグラフ - kなんとかの日記

明後日なコメントありがとうございます。ここでアセンブラを出してくるところがさすがすぎ。これでVelocity/JSPが遅いことの言い訳のつもりだから恐れいる。

woinary 静的な言語に動的な仕組みをなぜ入れるのかって？／ロジックは比較的静的だけど、画面や帳票の文言は動的だからだよ。／職業プログラマなら常識だと思ってた。 2010/04/30

『画面や帳票の文言は動的だから』JSPやVelocityが動的言語を導入した？そんなの、まるっきり関係ないよね。世の職業プログラマがここまでバカとは残念。

kohei_april20 ウェブの１リクエストに対してそれぞれ処理をするようなテンプレートエンジン的な役割に、処理速度はさほど重要じゃないと思うんだけど。ここがボトルネックになることはないでしょ。 2010/04/30

遅いテンプレートエンジンなら十分ボトルネックになる。それから結論は『言語の速度!=アプリの速度』だから、テンプレートエンジンがボトルネックになる・ならないは関係ない。

rokujyouhitoma テンプレートエンジン最速のPHP。これは面白い記事。結論ボトムネックになってるアプリケーション内のロジックを早期発見でき、修正しやすい言語が勝ちってことだな（時間帯効果的に）

あれは2年前のベンチマークですが、今ではテンプレートエンジン最速はPerlであることが判明しています。後半部分はその通りですが、より正確に言うと「ボトルネックを早期発見できるような*ツール*が利用できる言語」ですね。言語そのものよりは、ツールの問題。その点、IDEが発達しているJavaは有利なはずなんですけどね。

y-kawaz Javaの代表はVelocityかよ(^^; あれは扱いづらすぎて一度使えば追って後悔する 2010/04/30

Velocityよりましなのって何？ちなみにJ2EEの標準はVelocityよりクソなJSP+ELなんですが。

t_yano javaの文字列操作が遅い（少なくとも速いとは言えない）ってのは割と知られてることかと思っていた。 2010/04/30

Javaの文字列操作は十分速いっすよ。VelocityやJSPが遅いのはJavaの文字列操作が原因ではなく、単にアーキテクチャがバカなだけ。
このコメントだけじゃないけど、Java屋さんがいかにVelocity/JSPが遅い原因を分かってないか (そもそもVelocity/JSPが遅いことを知ってなかったか) がよくわかるコメント。

FTTH FTTH …… そりゃそうだわな。言語やコンパイラの性能差が問題になるのは最後の最後の最後と相場が決まってる。 2010/04/30

そのくせいつもは「Javaだから速い」と言いまくっているんですけどね、Java屋さんは。都合のいいときだけこういうワカッタフリをされる。

at_yasu "どれだけ早くコードを書けるか"の速度がない。言語の実行速度とアプリの実行速度が違うのは、情報工学では基本じゃないかな。 2010/04/30

『"どれだけ早くコードを書けるか"の速度がない』なんて当たり前じゃー！そこはまったく話題にしてないんだから。
きっとコメントした本人は、欠けている視点を指摘したつもりなんだろうけど。

fbis できることがまったく異なるテンプレートを並べて比較されても・・・。あとTenjinってテンプレートというか言語そのものなのでPHPが早いのは当たり前、最終的に生PHP吐いてるだけだから構文解析とかもほぼないし 2010/04/30

『言語の速度!=アプリの速度』という話なんだから、テンプレートエンジンでできることが異なったとしても関係ないよね？それにVelocity/JSP/PHP/eRuby/Djang.... の、具体的にどこが『できることがまったく異なる』のさ？
あと『最終的に生PHP吐いてるだけだから構文解析とかもほぼない』なんていうのはまるっきり勘違い。APC使わないPHPの場合はinclude()してるから毎回PHPの構文解析している。してないのはVelocityのほうで、一回作った構文木 (テンプレートオブジェクト) を使い回してあの速度。
元エントリをよく読もうよ、テンプレートオブジェクトを毎回作る場合と使い回す場合の両方でベンチマークしてると、ちゃんと書いてるんだから。
こういう、わかったつもりになっているコメントはたちが悪い。ついでに、自分では反論できないくせにこんなコメントに一生懸命なスターつけてる人たちもたちが悪い。

kurai プログラミング言語は速度で優劣つけるものじゃないから、こういう比較が無意味に見えて仕方がない。「速いが正義」ではないし、今は最適化されたソース＜保守しやすいソースだし。 2010/04/30

『言語の速度!=アプリの速度』という観点からは大変意味があります。

nanakoso ところでこのベンチマークＳＳＤ使ってるんだよね？ 2010/04/30

脚注読んで！I/Oは関係ないとちゃんと書いてあるよ！

fuki1234 結論がよく分からなかったｗ　言語の速度とアプリの速度は関係ないけどもテンプレートエンジンの速度とアプリの速度は関係あるってことなのかな。

元エントリに『今日のまとめ』とまで書いているのに、それでも結論がわからないのかー。ゆとりすぎだろ。

napsucks 重いJIT積んでるものはイニシャルコストがそれだけ高いからそこを無視したベンチマークで早さを競っても無意味ということだよね 2010/05/01

JVMの起動コスト・classファイルの読み込みコストは当然ながら除外されている。Javaな人はあら探しに一生懸命だな。

nekora C製のTenjinは大変偉いという話。

Cじゃねぇよー。Cだったら話がすべてひっくり返ってしまうでしょ。