アカウント名:
パスワード:
だからこそPHPでよりCでの方が効率が良い物に対してPECLというライブラリがあるわけでDB接続に関しても各DB関数のラッパーのPEAR::DBやPEAR::MDB2ではなくて処理的効率が良いPDOがあるわけで・・・・
それにしてもコンパイル型言語の方がそりゃインタプリタ型の言語より処理効率がいいのは分かり切っていることだけどCやC++で処理書いてサーバと同じクローン環境(基本的には本サーバと同じバージョンのライブラリなど)を作ってと考えると開発が非効率。その点Perl/PHPなどのスクリプト言語だとWindows環境でもテスト環境は構築できるから開発環境とテスト環境を同じにすることはできる。(ただしパーミッションやファイルロックなどはWindows系だとテストしきれない)でそこでJavaって話がでてくるわけで。
CやC++で処理書いてサーバと同じクローン環境(基本的には本サーバと同じバージョンのライブラリなど)を作ってと考えると開発が非効率。
VMwareでも使えば解決できそうだけど。
そんな速度的に限界がある仮想環境でコンパイル?どっちにしても非効率。コンパイルオプションでサーバにあわせてx86系CPUでもCPUアーキテクチャーにあわせたコンパイルして動作テストした場合にはテスト時の処理効率がさらに悪くなる。さらに今更ネタになると思うがサーバサイドがx86とは限らない。
そんな速度的に限界がある仮想環境でコンパイル?どっちにしても非効率。
VMwareも完全仮想化じゃなくて準仮想化を使えば十分な速度が得られると思うよ。Windows上のスクリプト言語での開発でOKという前提 [srad.jp]であれば、完全仮想化でも十分だと思うけどね。
さらに今更ネタになると思うがサーバサイドがx86とは限らない。
メインフレーム系は昔から仮想化をサポートしているし、UNIX系でもAIXのLPARとかSolarisコンテナとかもあるよ。十分検討に値すると思うけどな。まあ、小規模システムを単独で開発する場合にはメリットは出にくいわけだけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
なにが最適? (スコア:2, 参考になる)
だからこそPHPでよりCでの方が効率が良い物に対してPECLというライブラリがあるわけで
DB接続に関しても各DB関数のラッパーのPEAR::DBやPEAR::MDB2ではなくて処理的効率が良いPDOがあるわけで・・・・
それにしてもコンパイル型言語の方がそりゃインタプリタ型の言語より処理効率がいいのは分かり切っていることだけど
CやC++で処理書いてサーバと同じクローン環境(基本的には本サーバと同じバージョンのライブラリなど)を作ってと考えると開発が非効率。
その点Perl/PHPなどのスクリプト言語だとWindows環境でもテスト環境は構築できるから開発環境とテスト環境を同じにすることはできる。(ただしパーミッションやファイルロックなどはWindows系だとテストしきれない)
でそこでJavaって話がでてくるわけで。
Re:なにが最適? (スコア:1)
CやC++で処理書いてサーバと同じクローン環境(基本的には本サーバと同じバージョンのライブラリなど)を作ってと考えると開発が非効率。
VMwareでも使えば解決できそうだけど。
Re: (スコア:0)
そんな速度的に限界がある仮想環境でコンパイル?どっちにしても非効率。
コンパイルオプションでサーバにあわせてx86系CPUでもCPUアーキテクチャーにあわせたコンパイルして動作テストした場合には
テスト時の処理効率がさらに悪くなる。
さらに今更ネタになると思うがサーバサイドがx86とは限らない。
Re:なにが最適? (スコア:1)
そんな速度的に限界がある仮想環境でコンパイル?どっちにしても非効率。
VMwareも完全仮想化じゃなくて準仮想化を使えば十分な速度が得られると思うよ。
Windows上のスクリプト言語での開発でOKという前提 [srad.jp]であれば、完全仮想化でも十分だと思うけどね。
さらに今更ネタになると思うがサーバサイドがx86とは限らない。
メインフレーム系は昔から仮想化をサポートしているし、UNIX系でもAIXのLPARとかSolarisコンテナとかもあるよ。十分検討に値すると思うけどな。
まあ、小規模システムを単独で開発する場合にはメリットは出にくいわけだけど。