っていうかフリーのＦＷって、全部実行時コンパイルじゃないの？
ＦＷの意味半減だと思うんだが。

実行時コンパイルかどうかはフレームワークの問題じゃなくて実行環境の問題な気がするが
コンパイルが通るかどうかは別として他のフレームワークでつくってZendに食わせてもいいんだし

自分の知る限りではPHPだとアプリケーションサーバとして動作する
（メジャーな、実績のある）フレームワークは存在しないし、
mod_phpもmod_{perl,python,ruby}のような常駐型として作られていないので
リクエストごとにインタプリタが動きます。

ただ、それとフレームワークのメリットとは全くもって関係ないです。
Webアプリケーションフレームワークは生産性・保守性の向上のためのもの。
コンパイルのコスト軽減にはAPCやeAccelerator等を使うのが一般的。

超有名な
http://www.zend.co.jp/product/zendplatform.html
これは、ダメですか。そうですか。すごいですね。

>>503
アプリケーションサーバーかつフレームワークな実装もPHP以外なら存在するのはたしかだけど
それが一緒に提供されるメリットは感じないな。
その話とインタプリタの話がどうしてつながるのかわからないんだけど？

本当ですね。Zend Platformがフレームワークだったとは寡聞にして知りませんでした。

>>506
フレームワークなんて言ってないよ。（フレームワークとしての機能もあるけど）
PHPソースをコンパイルした状態で保持して実行するよって話

>>507
失礼。前半じゃなくて後半へのレスでしたか。

>>508
どうでもいいや。わけわかんねぇ

Zend使えばJavaみたいにVMの上で動いてるのと同じような感じなるわけだが、
それじゃ不満なんだろうか。
もちろんZendFrameworkじゃないフレームワークでも問題ないし。

>>510
Zendって省略しないで。それは会社名でしょ。
Zend PlatformでもVM上で動いているのと同じになるわけじゃないでしょ

>>510
金かかるんじゃねーの？

金かかるよ。それで？

最近の顧客はWebアプリケーションは無料と思ってるところ多いから、
その手のを請求したらケチつけてくるよ。ライセンスがどうなってるのか
しらねーけど。

Ａ「ＰＨＰで金が掛かるなんて聞いたことがないね」
Ｂ「フレームワークを使うからなんです。フレームワークを使えば
コードの保守・管理が楽になり色々とメリットが・・・」
Ａ「なるほど。あんたらが楽するためにこっちが金出せと？」

>>510のはフレームワークじゃなくてサーバじゃないの？
今はなきColdFusionみたいな

>Zend PlatformでもVM上で動いているのと同じになるわけじゃないでしょ

なるよ

>>516
ColdFusionはまだAdobeからFlexと併売されてなかったっけ?
ていうかColdFusionやFlexこそがフレームワーク込みのサーバ製品だよね。

Flexはともかく、ColdFusionをフレームワークというのは、
PHPそれ自体がフレームワークだ！っていう程度の意味しかないような。

PHPもアクセラレータ使ったら充分速いよ
だいたいYahooがPHPで動いてるんだから99％のサイトはPHPでおk

>>517
そのVMって、どういう意味？

>>514
Webアプリが無料って・・・もしかして、それホームページ？

>>520
PHPで大規模なサイトも作れますね！スゴイ（・∀・）
ちなみに私のホームページは、なんと！１日１００アクセスぐらいです＞＜

サーバが１台で済むような小規模サイトなら>>503の対策で十分ですよねー？＾＾
>APCやeAccelerator等を使うのが一般的

http://www.atmarkit.co.jp/news/200809/11/ruby.html
Rubyが遅い理由
遅いのにはいくつか理由がある。
1つは変数に静的型がなく、コンパイル時に型が決まらないことから最適化が効きづらいこと。
しかし、これは動的言語共通だ。
ほかにRubyが遅い理由として前田氏はRubyには「関数がなく、すべてメソッドであること」があるという。
ただ、Rubyは次期開発バージョンのRuby1.9系ではインタープリタをまるごと差し替え、バイトコードを処理するVM を採用したことで多くの最適化を実施し、大幅に高速化しているという。

Pythonも3.0になったことだし、PHPの包囲網は強力だぞ！！！
Perl6.0は(ry

>>517
VM＝ヴァーチャルマシンのこと。
Javaの仕組みで使われて有名だよ。
http://d.hatena.ne.jp/keyword/VM

>>520
Yahoo!JapanはあんまりPHPで動いてないぞえ
知恵袋とかはそうだけど昔からある部分はCかJavaだお

Zend EngineがJavaのVMっぽいってこういうことだな
http://journal.mycom.co.jp/special/2004/php5/004.html

そ、それ2000年の記事ですけど、PHP5でもそうなの？

いったんバイトコードにコンパイルしてからVMで実行するのはPHP4でも5でも6でも同じ。
PythonやRuby 1.9でも大ざっぱに言うと同様の仕組みになってる。
あとはVM(エグセキュータ)に手を入れてia32/amd64だけでもJITコンパイラが搭載されるとおもしろいのだけど。

勉強になりました。

>>528
どうでもいいけど俺には2004年に見える

>>528
どうでもいいけど俺にはPHP5の記事に見える

>>527 >>529
普段意識してなかったけど、PHPってそうなってたんだ！
参考になりました。

PHPフレームワークの本が揃い、使いやすい状況にある。
ダントツ１位がないのは、それぞれ一長一短だからだろうか？
各FWのユーザーから、「この実装は、このFWではこうやっているよ。メリットはこれこれ。」という報告をよろしく！
FW同士、切磋琢磨していいとこ取りをしよう！

他のLL言語のメリット・デメリットはこちらもどうぞ
http://pc11.2ch.net/test/read.cgi/tech/1215319832
【Perl,PHP】LLバトルロワイヤル3【Ruby,Python】

>>534
× こちらもどうぞ
○ こちらでどうぞ

でいいだろｗ

mod_phpが常駐しないことのメリットは、なんと言ってもデプロイが簡単なことだな。単にファイルを差し替えるだけでいいんだから。
そして、これで十分なスピードがある。
スクリプト言語の処理速度の差なんて、ウェブに限って言えばどうでもいいレベル。速度差はDB部分にかかってるわけで。

いやそんなことない。
DB部分は殆どキャッシュされてるがアクセスの多いページ、例えばサイトトップとか。

重箱の隅をつつくようで悪いけど、mod_phpそのものは常駐してますやん。
バイトコードやシンボルテーブルはリクエストの度に初期化・実行・破棄されるけど。
あとは同意。

はてなとかmixiくらいになるとその差が重要になってきて
だからわざわざめんどいmod_perl使ってるんだろ

>>537
そういうのはコンテンツキャッシュでどうとでもなる。

mixiは知らんけど、はてなの場合は中の人がPerlを使える・Perlを使いたい、
かといってCGIは遅すぎるのが理由な希ガス。

mod_perlとは懐かしい響きだ
それは確かに面倒くさそうだ。てか、未だにメンテされてるの？

常駐するから速いとも一概に言えないじゃん
Rubyなんて常駐させても遅いよ

RubyもいいけどPHPもね
http://searchblog.yahoo.co.jp/2007/09/php_at_yahoo_japan.html

世紀末Web土方伝説～LLの拳～
例えるなら、
Python（グーグル）…ラオウ
Ruby（楽天）…トキ
PHP（Yahoo）…ケンシロウ
Perl（はてな）…ジャギ
というポジションでしょうか？（・∀・）

Perlは（現状ではなく）役割的にはリュウケンのような気もするが

わかりやすく芸人に例えてくれ

楽天はRuby殆ど使ってないぞ
99%がPHPとJava
研究してるけど全く表に出てこないｗ

わかりやすく実写版ドラゴンボールに例えてくれ

よけいわかりにくいわｗ