フレームワーク(？)について

フレームワーク(？)について疑問があります。

数年前にでてきた.NETフレームワークを含めて、
J2RE、VBランタイム、Adobe AIRなどのフレームワーク(？)上で
動作するアプリケーションは、
・起動が遅い
・操作反応が遅い
など、感じることがあります。
(PCのスペックにもよると思いますが）

(1)将来的に重さは解消されるのか？
ハードウェアの進歩は速く、数年前のものの倍以上の性能をもつ
ものが日々開発されてきました。そのようなハードウェアがあったからこそ
フレームワークのような大規模なソフトウェアが生まれてこれたと思いますが、
フレームワークは、ハードウェアの許容する能力を超えるようなソフトウェアに
なってしまっているのが、現状だと思います。

「～～の法則は（名前は忘れました）
近いうちに収束するだろう」というような文章も目にしたことがあります。
近い将来のハードウェアでは、ネイティブアプリと同等、もしくは比較的
近いレベルの使い勝手(起動時間、操作反応)になるのでしょうか？

工学系には疎いので、そのような流れはあるのかを、知りたいです。
また、現在使い始めて、将来役立つような開発環境選択の参考に
したいです。

(2)「重い」原因は？
# 基本的なことだろうとは思いますが、、、
フレームワークを用いたアプリケーションが重いのは、中間言語を
実行時に機械語に翻訳していることが、主たる原因でしょうか？

CPUの使用率が高い→中間言語を機械語に翻訳しているから。
メモリの使用率が高い→フレークワークを実行するから。
とか思っているのですが、当たっていますでしょうか？

No.1 ベストアンサー 回答者： auty 回答日時： 2008/03/21 11:26

>>> (1)将来的に重さは解消されるのか？

仰せの通り、今問題となっているフレームワーク自身に関しては、ハードウェアの進歩により解消されるでしょう。しかしさらに巨大なフレームワークも現れます。
いわゆる「イタチの追いかけごっこ」です。

>>> )「重い」原因は？
は、中間言語を使わない物もあるわけですから、やはりフレームワークによる自動化が巨大なシステムを作り上げているということが大きいです。個々による効率化が妨げられているわけです。このあたりがもう少し調和がとれてくればと思うのですが。

この回答へのお礼

ご回答ありがとうございます。

「イタチの追いかけごっこ」というのは、とても納得できる
言葉です。

重い原因の回答は私の知識不足で理解できませんでした。。

お礼日時：2008/06/21 12:04

No.2 回答者： neko_noko 回答日時： 2008/03/22 23:01

コンパイラ言語の場合、コンパイル作業により機械語になっていますから、

プログラム(ネイティブコード)→コンピュータ
というようにダイレクトに処理しますで(細かい部分は省略)、
その性能はハードウェアに依存するとおよそ考えて良いですが、
中間言語を使用する.NET FrameworkやJREの場合、
プログラム(中間コードなど)→実行環境(.NET Frameworkなど)→ネイティブコード→コンピュータ
と、処理がいくつかあるので、ハードウェア性能以外の部分で遅さが出ることがあります。
主に、バイトコードを処理する部分です。
ここでの処理が簡潔にできれば、ネイティブコードに近い速度がでる可能性があり、
一方で、ここで無駄な処理が多ければそれだけ時間がかり、遅くなることもあります。

これを決める要因は何かと言うと、「コンパイラの性能」と「実行環境の性能」と言えると思います。
前者は、ソースコードから中間コードを作成するコンパイラが、どれだけ実行環境に負荷のかからないコード、
つまり「実行しやすい」コードを作れるか、ということです。
人間が書きやすい処理≠プログラムの実行しやすい処理でない時、
コンパイラが自動的にプログラムの実行しやすい処理に書き換えられれば、
(若干かもしれませんが)処理が速くなることもあります。
後者は、本来遅くなる処理を実行環境がどれだけユーザに遅く感じさせないか、などがあります。
JavaのJITコンパイラが有名で、ネイティブコードへの変換を最初にまとめて行うことで、
実行中にいちいち変換することがなくなり、速度の向上を図っています。

とまあ、いろいろ専門的なことを言ってますが、
要するに「間に処理を挟んでる分、いろいろ可能性がある」ということです。
理論上、どうがんばってもネイティブコードには勝てませんが、
それに近づける努力をすれば、ネイティブコードと遜色ない
(人間には速度差が実感できない)ものができる(かもしれない)、
ということです。
程度の差はあれ、どの言語でも努力はしていると思います。

あとは、プログラムを作る開発者の問題や、想定している実行環境などがある気もしますが、
個人的な意見だし、何よりこれ以上長文になると怒られそうなので、省略します。


余談ですが、
>「～～の法則は（名前は忘れました）

これは、「ムーアの法則」だったと思います。

この回答へのお礼

詳細な回答ありがとうございます。

フレームワークがあるおかげで負担が減っているのは
確実なことだと思います。
開発者の負担が減り、さらにはネイティブコードにも劣らない
性能を出したいという欲求を叶えるためには、
#1さんの回答のいたちごっこがずっと続くという予想も踏まえると
下記のようなトレードオフ関係(考慮点がぜんぜん足りないかもしれま
せんが。。)を頭に入れて、フレームワークの選択をしていく必要が
あるのかも知れませんね

・開発期間、人員、技術力
・そのフレークワークの性能、特徴
・そのフレークワークの枯れ具合
・そのフレークワークが必要とするスペック
・そのフレークワークが向いている用途

お礼日時：2008/06/21 12:29