プログラムのサイズがなぜそれほど大きいのですか？
ビンテージプログラムのNetscape Navigatorまたは初期バージョンのMicrosoft Wordを見ると、これらのプログラムのサイズは50 MB未満でした。 google chromeをインストールすると、200 MBで、Slackのデスクトップバージョンは300 MBです。プログラムが使用可能なすべてのメモリをいくら使用してもすべてのメモリを使用するというルールについて読みましたが、なぜですか？
現在のプログラムのサイズが10年または15年前に比べて非常に大きいのはなぜですか？プログラムは大幅に多くの機能を実行しておらず、外観も大きく異なりません。現在リソースを独占しているのは何ですか？
「非常に異なって見える」ことは、知覚の問題です。今日のグラフィックスは、以前とはまったく異なる画面解像度で見栄えをよくする必要があるため、以前はロゴとして十分に優れた100x100の画像でも、ひどく粘着性に見えます。同じものの1000x1000の画像に置き換える必要があり、これは100倍の係数です。 （代わりにベクターグラフィックスを使用できることは知っていますが、それは要点を強調するだけです-ベクターグラフィックスレンダリングコードは、以前はそれを必要としなかったシステムに追加する必要があったため、これは1種類のサイズ増加とのトレードオフにすぎません。別のものに。）
「異なる働き方」も同様に知覚の問題です。今日のブラウザは大規模 1995年のものよりも多くの機能を備えています。（雨の日、歴史的なラップトップでインターネットをサーフィンしてみてください。ほとんど使用できません。）あまり使用されていません。使用はそれらの90％を完全に認識していない可能性がありますが、それらはそこにあります。
その上、もちろん、スペースの最適化により多くの時間を費やすのではなく、新しい機能の導入により多くの時間を費やす傾向があります。これは、誰にとってもより大きく、より速く、より安価なコンピュータの自然な副作用です。はい、1990年と同じくらいリソース効率の高いプログラムを作成することが可能であり、その結果は驚くほど高速で滑らかになります。しかし、もう費用対効果は高くありません。ブラウザーが完了するまでに10年かかり、その時点で要件は完全に変更されていたはずです。往々にして、昨今の低速で小型のマシンはそれを余儀なくされ、他の誰もがそれをやっていたので、人々は効率に非常に注意を払ってプログラミングをしていました。これが変更されるとすぐに、プログラムの成功のボトルネックは、実行可能から実行可能になり、実行に移行しました。より光沢のあるもの、そしてそれが私たちが今いるところです。
1つの理由は、アプリケーション内にパッケージ化されたデータは、解像度と品質が高いため、サイズが大きいことです。 Netscapeの時代のアイコンは最大で32x32ピクセル、最大で8ビットの深さ（おそらく4ビットのみ）でしたが、現在はおそらく64x64のようなものであり、透過性のあるトゥルーカラーで、32ビットの深さを意味しています。それは16倍大きいです。また、スペースが非常に安いため、PNGを生成するときに、「圧縮」オプションをチェックする必要さえありません。
もう1つの理由は、最近のアプリケーションでは、以前のアプリケーションではできなかった、驚異的な量のデータが使用されるためです。 「はじめに」のプレゼンテーションと一緒に出荷されるアプリケーションが今日存在しますin video。
もう1つの理由は、今日のプログラミング言語は、かなり大規模な豊富なランタイム環境とそれぞれ100MBのチューニングに対応する傾向があるためです。ランタイム環境のすべての機能を使用しなくても、すべてをアプリにパッケージ化する必要があります。
しかし、その主な理由は、今日、アプリケーションで使用できる膨大な数のライブラリが存在し、常にホイールの再発明を回避するためにライブラリを使用する文化を発展させてきたことです。もちろん、ライブラリの使用を開始すると、いくつかの質問がポップアップし、私たちはそれらに最も寛大な答えを与える習慣を身につけました：
私の関数の1つだけで使用される場合、さらに別のライブラリを含めることは価値がありますか？ --はい
そのライブラリーが提供する豊富な機能全体のごく一部のみが必要な場合に、さらに別のライブラリーを組み込むことは価値がありますか？ --はい
さらに別のライブラリを含めると、2日間の作業から私を救うだけの価値がありますか？ --はい
給与計算の異なるプログラマーが異なるライブラリーにすでに慣れているというだけの理由で、多かれ少なかれ同じ目的を果たす複数のライブラリーを含めることは価値がありますか？ --はい
（私はこれらの傾向を観察しているだけであり、私がそれらに同意するかしないかについては何も述べていません。）
言及する価値があるもう1つの理由は、いくつかの選択肢の中から使用するアプリケーションを決定しようとするときに、一部のユーザーthinkより多くのスペースを占めるものは、より機能満載で、より洗練されたグラフィックスなどになることです（もちろん、これはまったくナンセンスです。）
結論として、ソフトウェアはガスのように動作しますか？使用可能なすべてのスペースを占める傾向がありますか？ある意味ではそうですが、驚くほどではありません。ドライブで最も多くの領域を占めるものを見ると、ほとんどの場合、それはアプリケーションではなく、映画や音楽などのメディアであると答えていますはるかに。ソフトウェアは、ストレージ容量が拡大しているのと同じ速度で膨れ上がっておらず、今後もそうなる可能性は低いため、将来のアプリケーションは、利用可能なストレージスペースの無視できる割合を表す可能性がありますユーザー。
他のansersに加えて、10年前は通常、ローカライズ版/国際化版の個別のバージョンがありました。現在、プログラムは、プログラムサイズを埋めるすべてのリリースバージョンに完全なローカリゼーションサポートをバンドルする場合が一般的です。
1つの理由は依存関係です。豊富な機能と見栄えの良いプログラムには、暗号化、スペルチェック、XMLとJSONの操作、テキスト編集など、さまざまな処理が必要です。彼らはどこから来るのでしょうか？多分あなたはあなた自身のものを転がして、それらをできるだけ小さくしておくでしょう。ほとんどの場合、実際には必要のない多くの機能を備えたサードパーティコンポーネント（MITライセンスのオープンソース）を使用しますが、サードパーティコンポーネントの単一の機能が必要になると、コンポーネント全体を持ち歩く必要があります。したがって、依存関係をどんどん追加していくと、依存関係自体が進化して成長するにつれて、依存関係に依存するプログラムも成長します。
グラフィックス/使いやすさは確かに要因ですが、ライブラリ/過剰にコンパイルされたコードは非常にたくさんあります。
小さなコードの例：MenuetOS、単一のフロッピーディスクに収まる強力なアプリを備えた完全な64ビットOS。
明らかな理由もなく、コードがどれほど大きいかを示す例：「Hello、World！」という単純なテキスト出力を行いました。エイダで最近。コンパイルされた実行可能ファイルは1 MiB以上でした！アセンブリ内の同じ実行可能ファイルは、KiBまたは2です（その大部分は実行可能オーバーヘッドであり、実際に実行されるコードは数十バイトです）。
ソフトウェアは、ユーザーと利用可能なハードウェアの2つに適合するように構築する必要があることは自明です。ユーザーが自由に使用できるハードウェアを使用して、ユーザーがタイムリーに望んでいることを実行する場合、プログラムはその目的に適しています。まあまあ。しかし、ハードウェアが基本的にすべての測定可能な次元で改善するにつれて、不適合から適合に移行する個別のプログラムの数が増加します-設計スペースが大きくなります。
- 高級言語これまでよりも少ないコードと時間でアイデアを表現できるようになります。逆に、これにより複雑さが低下し、ますます複雑になるアイデアを表現することが可能になります。
- バンドルアプリケーションのデータが増えると、すぐに使いやすくなります。たとえば、スペルチェックアプリケーションが人類に知られているすべての言語にバンドルされるようになるまでには、それほど時間がかかりません。結局のところ、数ギガバイトしかありません。
- ハードウェアのトレードオフ開発者とユーザーが気にするリソースをより多く選択できるようにします。たとえば、FLAC/OGGとWAV、SVGとPNG、データベースインデックスをご覧ください。
- Humaneインターフェース使いやすさのために、以前は膨大な量のハードウェアとなるものをトレードオフすることがよくあります。アンチエイリアシング、高解像度、高速リフレッシュ、および個別のパネルに相当する量の間のスワイプにより、すべてがより現実的で直感的で関連性のあるエクスペリエンスを実現します。
これはAndroid=アプリケーションについては間違いなく当てはまります。4年前、シンプルなアプリは約2〜5メガバイトのスペースを必要としました。現在、シンプルなアプリは約10〜20メガバイトのスペースを必要とします。
使用可能なスペースが大きいほど、アプリのサイズが大きくなります。
Androidの場合、主に2つの理由があると思います。
GoogleはAndroidフレームワークを拡張し、多くの新機能を追加しました。
開発者はもう気にしません。画像ははるかに高い解像度で含まれています（もちろんスマートフォンの画面解像度が高くなっています）。
その多くは、開発者の時間とその時間のコストに要約されます。 Visual Basicが最初に登場した当時は、C/C++と競合しており、大きな打撃はANSI C for Windowsで「Hello World」を15Kで書けることでした。 VBの問題は、300Kランタイムライブラリのアルバトロスが常にあったことです。
これで、VBプログラムのサイズを10倍にすることができますが、それでも数Kは増えますが、C/C++プログラムのサイズの10倍であり、数か月間しか見ていません。より多くの開発。
結局のところ、アプリケーションの肥大化は、開発生産の大幅な飛躍、価格の削減、そして手作業で作られた昔の開発では決して不可能だったであろう膨大な機能に対抗するための小さな価格です。プログラムが小さくて高速であるだけでなく、弱く、互いに互換性がなく、機能が不十分で開発にコストがかかる場合。
時がたつにつれて、ユーザーのニーズは進化し、ますます厳しいものになるため、さまざまなソフトウェアのベンダー/作成者は、競争という名目でそれらのニーズを満たすことを余儀なくされています。
しかし、新しいニーズを満たすことは、しばしば新しいコードを追加することを意味します。新しいコードは、修正する新しい脆弱性を意味します。新しい脆弱性を修正すると、コードが追加されたり、新しい脆弱性の扉が開かれたりする可能性があります。
ユーザーのニーズを満たすために追加された各機能には、速度（このブラウザーまたはそのブラウザーの速度について不満があります）のためのより多くのプロセッサー能力、より良い視覚効果のための新しいグラフィックリソースなどが必要になる場合があります。
これはすべて、アプリケーション（コード）、セキュリティ、場合によってはハードウェアの新しいレイヤーを追加することを意味します。
サイズの多くは、組み込みライブラリに由来します。最近の多くのアプリケーションは、アプリケーションに膨大な量をバンドルする電子を使用して構築されています。 Linuxにアプリケーションをインストールする場合、他のプログラムも使用している共有ライブラリを介してアプリケーションの多くがすでにインストールされているため、アプリケーションは通常はるかに小さくなります。