アカウント名:
パスワード:
Javaで気付かなかったのかね?JVMとか互換性無視してまで応答性を上げようとしたはずなのに。同じ轍を踏むとかアホかと。
Perl/Python/Ruby なんかは Apache httpd にモジュールを組み込んだり FastCGI や Passenger などでコンパイル済みイメージをメモリー上にキャッシュする事で高速化しますし、Java でも Tomcat なんかは結局その形ですよね。 .NET も何も考えずに IIS の領域に配置して実行したような場合はそうなりますが、実行時にコンパイルやセキュリティーチェックなどを行わず、事前に済ませてストレージ上にキャッシュしておき、実行時にそのキャッシュを読み込む (= ほぼネイティブバイナリーを読み込む形) ようになっています。ngen や JIT による MSIL のネイティブコード最適化も環境に合わせた最適化が行われるようになっていますね。 JavaScript でサイトごとに有名どころのスクリプトファイルを読むよりは CDN から取得した方がキャッシュが効きやすいよね、なんていうのもある意味似たような話ではあると思いますが。
「バイナリを吐」くというのは当然環境ごとに最適なバイナリーを使用する、という事ですよね。当然 x86 とか x64 なんていう大雑把なアーキテクチャーレベルではなく、プロセッサーごとに最適なバイナリーを利用する、というレベルですよね。80386 最適化 (笑) バイナリーとか出されても今時困るだけですし。 でも、そういうレベルって *BSD や Gentoo Linux などでもそこまでビルドオプションを詰めている人はあまりいないと思いますが、どうでしょうか。パッケージから突っ込んでる人なんて論外ですよね。 ある程度勝手にそういったレベルでの「ほぼバイナリー」を生成するこの更新インストール過程は、あなたの望んでいる状況に比較的近いのではないですか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
バイナリ吐かない環境は役に立たない (スコア:0)
Javaで気付かなかったのかね?
JVMとか互換性無視してまで応答性を上げようとしたはずなのに。
同じ轍を踏むとかアホかと。
Re:バイナリ吐かない環境は役に立たない (スコア:1)
Perl/Python/Ruby なんかは Apache httpd にモジュールを組み込んだり FastCGI や Passenger などでコンパイル済みイメージをメモリー上にキャッシュする事で高速化しますし、Java でも Tomcat なんかは結局その形ですよね。
.NET も何も考えずに IIS の領域に配置して実行したような場合はそうなりますが、実行時にコンパイルやセキュリティーチェックなどを行わず、事前に済ませてストレージ上にキャッシュしておき、実行時にそのキャッシュを読み込む (= ほぼネイティブバイナリーを読み込む形) ようになっています。ngen や JIT による MSIL のネイティブコード最適化も環境に合わせた最適化が行われるようになっていますね。
JavaScript でサイトごとに有名どころのスクリプトファイルを読むよりは CDN から取得した方がキャッシュが効きやすいよね、なんていうのもある意味似たような話ではあると思いますが。
「バイナリを吐」くというのは当然環境ごとに最適なバイナリーを使用する、という事ですよね。当然 x86 とか x64 なんていう大雑把なアーキテクチャーレベルではなく、プロセッサーごとに最適なバイナリーを利用する、というレベルですよね。80386 最適化 (笑) バイナリーとか出されても今時困るだけですし。
でも、そういうレベルって *BSD や Gentoo Linux などでもそこまでビルドオプションを詰めている人はあまりいないと思いますが、どうでしょうか。パッケージから突っ込んでる人なんて論外ですよね。
ある程度勝手にそういったレベルでの「ほぼバイナリー」を生成するこの更新インストール過程は、あなたの望んでいる状況に比較的近いのではないですか?