kなんとかの日記 このページをアンテナに追加

2010-06-03

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

| 09:18 |  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

no title

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

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

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

kohei_april20 ウェブの1リクエストに対してそれぞれ処理をするようなテンプレートエンジン的な役割に、処理速度はさほど重要じゃないと思うんだけど。ここがボトルネックになることはないでしょ。 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 ところでこのベンチマークSSD使ってるんだよね? 2010/04/30

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

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

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

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

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

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

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

sinhsinh 2010/06/04 07:51 テンプレートエンジンってことは画面表示部分についてのみでは、Perl,PHP>Javaってことはわかるけど、
サーバ側のビジネスロジック、DBアクセスなどは
ベンチの早いC,Java > Perl,PHPではないでしょうか?
それらをトータルで考えると、C,Java,Perl,PHPどれをとってもたいして変わらないってこと?

kwatchkwatch 2010/06/04 11:17 > テンプレートエンジンってことは画面表示部分についてのみでは、Perl,PHP>Javaってことはわかるけど、
違います。PHP > Velocity/JSP です。ライブラリの問題であって言語の問題じゃない。

> サーバ側のビジネスロジック、DBアクセスなどは
> ベンチの早いC,Java > Perl,PHPではないでしょうか?
DBアクセスも言語による違いはありません。たいがいのスクリプト言語ではCで書かれたドライバがあるためです。
http://d.hatena.ne.jp/kwatch/20100501/1272677385
を読んでください。
ビジネスロジックに関しては、同じロジックを実行するならCやJavaのほうが断然速いです(ビジネスロジックに関係なく)。そして、これもビジネスロジックの設計やアーキテクチャで大きく処理量が異なるので、「同じロジックを実行するなら」という前提自体があんまり成り立たないんですよ。100行程度のコードですら、うまい人とヘタクソとでは大きな違いがあるのだから、アプリケーションの設計に至っては、ビジネスロジックが同じになるわけがない。
前にヨドバシドットコムがひどい性能だった事件がありましたが、あれはJava+Weblogicを使っていてああなったことを考えれば、ビジネスロジックの実行が速いかどうかは、言語以外の要素のほうが大事だと思いませんか?
アプリケーションの性能は総合的なものであり、言語の速度はその要素のひとつでしかなく、データ構造やアーキテクチャの選択、キャッシュの有無、SQLの熟練度、I/Oやネットワークのボトルネック具合、といったもののほうがよほど大きな影響を与えます。
でも、そういった言語に依存しない部分を含めたベンチマークをしても、「言語の速度 != アプリケーションの速度」という主張はなかなか受け入れられないでしょう。そうじゃなくて、キャッシュやI/Oのような明らかに言語に依存しない部分を取り除いた、ただのライブラリのベンチマーク結果のほうが、「言語の速度 != アプリケーションの速度」という主張に説得力を持たせることができます。
少なくとも、Javaの世界でデファクトスタンダードとして使われているJSPやVelocityがあの程度の速度でしかないという事実は、「言語の速度 != アプリケーションの速度」という主張を裏付けるに十分だと思います。

> それらをトータルで考えると、C,Java,Perl,PHPどれをとってもたいして変わらないってこと?

『それら』の中に、上で挙げたこと (データ構造やアーキテクチャの選択、キャッシュの有無、SQLの熟練度、...) が含まれているなら、*アプリケーションの速度については*その通りです。

はなこはなこ 2010/06/04 14:37 JSP 勘違いしてない?

JSP を初めて読み込むと、開発サーバーによって Java ソース コードに変換され、その Java ソースが Java バイトコードにコンパイルされます。Java ソースとコンパイル済みのクラスは、一時ディレクトリに保存されます。元の JSP ファイルに変更を加えると、JSP が自動的に再生成されてコンパイルされます。

JSP の使用 - Google App Engine - Google Code
http://code.google.com/intl/ja/appengine/docs/java/gettingstarted/usingjsps.html

kwatchkwatch 2010/06/04 17:16 > JSP 勘違いしてない?

どこをどう勘違いしたと思ってらっしゃる?

はなこはなこ 2010/06/04 19:00 書いてる通りですけど、JSP や Velocity は実行前にはすでにサーブレットに変換され、コンパイルされており、インタプリタ言語のように JSP の構文を解析しながら実行されるものではありません。
コンパイルするのでこの時点で構文エラーもチェックされており、
ここで仰っている動的、静的で言うならば、静的だと思います。

はなこはなこ 2010/06/04 19:16 Velocity はコンパイルされないようですね。

kwatchkwatch 2010/06/04 19:54 > 書いてる通りですけど、JSP や Velocity は実行前にはすでにサーブレットに変換され、コンパイルされており、インタプリタ言語のように JSP の構文を解析しながら実行されるものではありません。

まことに残念ですが、インタプリタ言語を勘違いされてます。
Perl/PHP/Python/Ruby/JavaScriptといった現代のインタプリタはどれも、実行に先立って構文解析を済ませてから実行されます (あるいは「実行」が「構文解析」と「評価」の段階に分かれていると考えられる)。それはVelocityやJSPと動作は変わりません。
『構文解析をしながら実行』するタイプのインタプリタは、今ではシェルスクリプトぐらいじゃないでしょうか。
あと、Velocityはサーブレットに変換されません (サーブレットに依存しないのがVelocityの利点のひとつなので)。VelocityにはVelocityServletというユーティリティクラスが付属しますが、それはVelocityのテンプレートファイルが『サーブレットに変換』されることは意味しません。

> コンパイルするのでこの時点で構文エラーもチェックされており、

ここで言っている『コンパイル』とは構文解析のことでしょうか。その時点で構文エラーがチェックされるのは、Perl/PHP/Python/Ruby/JavaScriptでも同じです。
もしJSPをServletへ*変換*することを『コンパイル』と称しているなら、Velocityには当てはまらないので、『コンパイル』などと言わず、ふつうに「Servletへ変換される時点で構文エラーもチェックされており…」と書いたほうがいいでしょう。
バイトコードへの変換のことを言っているなら、これもVelocityには当てはまらないので、もっと正確な言葉で書かれたほうがいいです。あとバイトコードに変換されることと、実行に先立って構文エラーがチェックされることは、別のお話です。

> ここで仰っている動的、静的で言うならば、静的だと思います。

ここでいう動的・静的は、型付けについてです。Veloctyも、JSPのELも、静的な型ではなく動的な型付けを行うので、動的な言語です。
コンパイルを行うかどうかとか、構文解析をいつ行うかはまったく関係ないことに注意してください。たとえばPythonは事前にバイトコードに*コンパイル*できますが、動的な言語です。

というか、JSPやVelocityが静的だという意見は初めて聞きました。それがほんとに正しいか、周りのJava屋さんに聞いてみてください。「動的だ」と即答してもらえるはずですから (もし即答できないような人なら、その人は大して分かってないので無視していいと思います)。
#んー、でもEL抜きならJSPは静的と言えるのかな?EL抜きのJSPをJSPと呼ぶかどうかは別として。

はなこはなこ 2010/06/04 20:29 先に
> Velocity はコンパイルされないようですね。
と書いてます。Velocity のしくみはおっしゃる通りのようですが、
Velocity と JSP はしくみが違います。

Velocity - You make the decision - Generation?
http://www.jajakarta.org/velocity/velocity-1.2/docs-ja/ymtd/ymtd-generation.html

> Perl/PHP/Python/Ruby/JavaScriptといった現代のインタプリタはどれも、実行に先立って構文解析を済ませてから実行されます。

承知しています。

言いたかったのは、
"JSP は実行前にサーブレットに変換されスタンバイしてます。" っていうことです。
JSP が遅いということは、サーブレットが遅いと言っていることと同じに思えたのでコメントしました。

kwatchkwatch 2010/06/04 22:59 >先に
>> Velocity はコンパイルされないようですね。
>と書いてます。

ああ、すみません。はなこさんがそう書く前に、自分のコメント書き始めたので。

> Velocity のしくみはおっしゃる通りのようですが、
> Velocity と JSP はしくみが違います。

はいそうですね。最初からわかってます。

> 承知しています。

いえ、理解されてないでしょ。ご自身で
『インタプリタ言語のように JSP の構文を解析しながら実行されるものではありません。』
と書いたのをお忘れですか。現代のインタプリタが構文解析されてから実行することを理解してたら、こんなこと書きませんよ。

> 言いたかったのは、
> "JSP は実行前にサーブレットに変換されスタンバイしてます。" っていうことです。

はい、知ってます。それが今回の話とどう関係があるのでしょうか。
#正確に言うと、「実行前」ではなく「アクセスがあってから」ですけどね。
#まあ設定によっては起動時にすべてコンパイルさせることも可能でしょうけど。

> JSP が遅いということは、サーブレットが遅いと言っていることと同じに思えたのでコメントしました。

うーん、なんでそういう誤解をするかな。
「JSPが遅いのは動的な言語を導入したから」と本文にちゃんと書いてるので、もう一度読んでください。
「JSPが遅い」イコール「サーブレットが遅い」と読み取ったのは、そちらの完全な誤読です。

kwatchkwatch 2010/06/05 00:49 > うーん、なんでそういう誤解をするかな。

あーわかった。「動的な言語」という意味が分かってないから、コンパイルがどうのこうの言ったり、『JSP が遅いということは、サーブレットが遅いと言っていることと同じに思えた』りするわけですね。なるほど。ようやく理解できました。
前のコメントで説明しましたが、「動的な」言語というのは実行時に型付けを行う言語のことであり、コンパイルがどうのこうのは関係ありません。そして、JSPではEL (Expression Language) という動的な言語が正式な仕様として導入されており、これがJSPが遅いことの主要因です。事前にサーブレットに変換されることはまったく無関係です。
ご理解していただけましたでしょうか。ご理解できたらYesと、理解できなかったら理解できない点を書いてください。よろしくお願いします。

はなこはなこ 2010/06/06 01:00 jsp は遅延評価使わなければ静的では。jsp 使う時 el 必須とは思ってない。el 限定の話ならタイトル変えて欲しい。最初から読まないから。

kwatchkwatch 2010/06/06 03:09 > jsp は遅延評価使わなければ静的では。

『遅延評価』が何か分かってないようです。動的言語は遅延評価とは関係ありません。
いくらなんでも勉強不足では?

> jsp 使う時 el 必須とは思ってない。

えー、今は必須でしょう。EL使わずJSP使ってるのですか。それは周りに迷惑でしょう。

> el 限定の話ならタイトル変えて欲しい。最初から読まないから。

いやいや、そちらが勉強不足のせいで勝手に勘違いしてただけじゃないですか。それを反省せずに、相手を非難ですか。これがJava屋さんクオリチーか?。

しじみしじみ 2010/06/18 16:14 PageContextImpl#roprietaryEvaluate
が、遅い、って言ってるってことでしょうかね?

しじみしじみ 2010/06/18 16:57 >PageContextImpl#roprietaryEvaluate
PageContextImpl#proprietaryEvaluate
です orz

PHPPHP 2011/06/30 16:47 PHPは前使ってたことあるけど、あれが「開発効率良い」とはとても思えない。バグ取りの労力が、半端でない。一人でコーディングする人にはいいのかもしれないけど、ある程度のチームを組んでやろうとするときには、PHP<Ruby<Javaだと思う。

通りすがり通りすがり 2012/01/04 00:56 jspが遅いのはjspが導入された当初から言われていましたが......phpは出たばっかり..実績なし、CGI:perlはマルチスレッドのバグにて印象最悪.....CGI:Cは概念がまだない......HTMLクラスをOutputStreamしていたよりはHTMLから修正しやすいjspが主流になった....jspくそ遅いけど..使うのと当時はいわれましたが、選択がなかった。だってデザイナーがころころHTMLを変えていたし。日替わりで対応するにはjspは「開発効率が良い」し、javaにてといえば実績があったし<=これが一番強いのかな。
ぜんぜん別物だけどね....

covacova 2012/02/11 18:24 主のコメントに大笑いでした。
すごく面白いやり取りをされてますね。
私もjavaはよく遅いなどと聞いて???がつく人間なんですが・・・
JSPを出してjavaが遅いなどというのも変な話です。
JSPなんてjavaのいちアーキテクチャでしかないわけで。
つまり、出来上がったアプリが遅いのはjavaが遅いからなんて言うのは違いますよね。
作り方が悪いだけでjavaのせいにされたらjavaが可哀そうです。
世のプログラマはレッテル貼る前に勉強しろってことです。

hogehoge 2012/03/04 18:17 あんた凄いね。
JSPが遅いって話で、JAVAは早いって書かれてるじゃん。

>つまり、出来上がったアプリが遅いのはjavaが遅いからなんて言うのは違いますよね。

だから「言語の速度!=アプリケーションの速度」なんでしょ、自分でも同じ答え出してるじゃん。よかったね。

通りすがってみた通りすがってみた 2012/04/07 08:54 Javaのことを"java"ってかいてみたり、
"JAVA"って書いてみたり、、、
そりゃ理解の差が出てるなぁと思った。

通り過ぎようとした猫通り過ぎようとした猫 2013/04/05 09:17 Javaな人を相手にパフォーマンスの話をしても、時間の無駄な事が多いです。悩みのタネです。

pc西谷pc西谷 2015/11/11 09:51 つまりPHP最強ということです

あれ?あれ? 2016/12/30 16:30 二元論したいわけではないけど。
covaさんは主さんサイド(に賛同)の意見をおっしゃっているのですよね?

0000 2018/07/13 22:04 appendって何かマズいんですか?