プログラムのサイズが大きいのはなぜですか？

古いプログラムNetscape Navigatorまたは初期バージョンのMicrosoft Wordを見ると、これらのプログラムのサイズは50 MB未満でした。google chromeをインストールすると、200 MB、Slackのデスクトップバージョンは300 MBになります。私は、プログラムがどれだけ多くのメモリを使用するかというルールについて読んでいますが、それはなぜですか？

現在のプログラムのサイズが10年または15年前に比べて非常に大きいのはなぜですか？プログラムはそれほど多くの機能を実行しておらず、見た目も大きく異なりません。現在、リソースを独占しているのは何ですか？

「非常に異なるように見える」ことは認識の問題です。今日のグラフィックスは、以前とはまったく異なる画面解像度で見栄えが良くなければならず、その結果、ロゴには十分すぎるほどだった100x100の画像は今ではひどく粘着性に見えます。同じものの1000x1000の画像に置き換える必要がありました。これは、100倍に相当します。（代わりにベクターグラフィックスを使用できることを知っていますが、それはポイントを強調するだけです-ベクターグラフィックスレンダリングコードは、それを必要としなかったシステムに追加する必要があったため、これは1種類のサイズ増加からのトレードオフです別の人に。）

「異なる働き方」も同様に認識の問題です。今日のブラウザがない大規模な 1995年からの1以上のもの（1雨の日の歴史的なノートパソコンでインターネットをサーフィンしてみます。 -あなたはそれがほとんど使用不可能だ見つけることができます）ではないそれらの多くは、非常に多く使用されている、と用途は90を全く知らないかもしれそれらの割合ですが、彼らはそこにいます。

それに加えて、もちろん、スペースのために物事を最適化するのに時間を費やさず、新しい機能の導入により多くの時間を費やすという一般的な傾向があります。これは、誰にとっても大型で、高速で、安価なコンピューターの自然な副作用です。はい、1990年と同じくらいリソース効率の良いプログラムを書くことができ、その結果は驚くほど高速で滑らかになります。しかし、もはや費用対効果は高くありません。ブラウザが完了するまでに10年かかり、その時点で要件は完全に変更されていました。かつては低速で小型のマシンを使用せざるを得なかったため、人々は効率に非常に注意を払ってプログラムを作成していました。すぐにこれを変更すると、プログラムの成功のためのボトルネックは、実行することができることからシフトまったく実行しますますます光沢のあるもの、そしてそれは私たちが今いる場所です。

Netscape Navigatorを最新のブラウザと比較すると、機能に大きな違いがあります。HTML 3.2仕様（印刷プレビューを行うと51ページ）と現在のHTML仕様（PDFバージョンは1155ページ）を比較するだけです。サイズが20倍になります。

Netscape NavigatorにはDOMもCSSもありませんでした！ドキュメントの動的な変更はなく、JavaScriptはDOMまたはスタイルシートを変更しませんでした。タブはありません。オーディオまたはビデオはありません。最新のブラウザは、非常に複雑なプログラムです。

1つの理由は、アプリケーション内にパッケージ化されたデータは解像度と品質が高いために大きいためです。Netscapeの時代のアイコンは最大で32x32ピクセルで、最大で8ビットの深さ（おそらく4）でしたが、現在はおそらく64x64のようなもので、透明度のある真の色で、32ビットの深さを意味しています。それは16倍大きいです。また、スペースは非常に安価であるため、PNGを生成するときに「圧縮」オプションをチェックすることさえしません。

もう1つの理由は、最近のアプリケーションには気が遠くなるほどの量のデータが含まれているため、古いアプリケーションにはありませんでした。現在、ビデオの「はじめに」プレゼンテーションと一緒に出荷されるアプリケーションがあります。

もう1つの理由は、現在のプログラミング言語は、それぞれが100 MBに達する、かなり大きなリッチなランタイム環境と連携する傾向があることです。ランタイム環境のすべての機能を使用していなくても、アプリ全体をパッケージ化する必要があります。

しかし、主な理由は、今日、私たちのアプリケーションで使用できる膨大な数のライブラリが存在し、ホイールの絶えざる再発明を避けるためにライブラリを使用する文化を開発したことです。もちろん、ライブラリの使用を開始すると、いくつかの質問がポップアップ表示され、それらに対して最もリベラルな回答をする習慣が開発されました。

• 私の関数の1つだけで使用される場合、さらに別のライブラリを含める価値がありますか？- はい。

• そのライブラリが提供する豊富な機能のごく一部のみが必要な場合は、さらに別のライブラリを含める価値がありますか？- はい。

• ライブラリを含めても2日間の作業で済む場合は、さらに別のライブラリを含める価値がありますか？- はい。

• 給与の異なるプログラマーが異なるライブラリーに既に精通しているという理由だけで、多かれ少なかれ同じ目的に役立つ複数のライブラリーを含めることは価値がありますか？- はい。

  （私はこれらの傾向を観察しているだけであり、それらに同意するかどうかについては何も言明していません。）

言及する価値のある別の理由は、いくつかの選択肢の中からどのアプリケーションを使用するかを決定しようとすると、一部のユーザーは、より多くのスペースを占有するものがより機能満載で、より派手なグラフィックなどを持つと思うことです（もちろん、これは完全にナンセンスです） ）

結論として、ソフトウェアはガスのように振る舞いますか？使用可能なすべてのスペースを占有する傾向がありますか？ある意味ではありますが、驚くほどの範囲ではありません。私たちはドライブにほとんどスペースを取るものを見れば、私たちのほとんどのための答えは、それはアプリケーションが、そのような映画や音楽などのメディアではないということですはるかに。ソフトウェアは、ストレージ容量が拡大しているのと同じ速度で肥大化しておらず、今後拡大する可能性は低いため、将来のアプリケーションは、ユーザーが利用できるストレージスペースのごく一部を占める可能性があります。

他の回答に加えて、10年前には、通常、ローカライズ版/国際化版用に個別のバージョンがありました。現在、一般的に、プログラムはリリースされたすべてのバージョンに完全なローカライズサポートをバンドルし、プログラムサイズを埋めます。

1つの理由は依存関係です。機能が豊富で見栄えのよいプログラムには、暗号化、スペルチェック、XMLおよびJSONの操作、テキスト編集など、多くの作業が必要です。彼らはどこから来るのでしょうか？たぶん、あなたはあなた自身を転がして、それらをできるだけ小さく保つでしょう。ほとんどの場合、実際には必要のない多くの機能を備えたサードパーティのコンポーネント（おそらくMITライセンスのオープンソース）を使用しますが、サードパーティのコンポーネントから単一の機能が必要になったら、コンポーネント全体を持ち歩く必要があります。したがって、依存関係をさらに追加し、依存関係自体が進化し成長するにつれて、依存関係に依存するプログラムも成長します。

グラフィックス/ユーザビリティは確かに貢献要因ですが、ライブラリ/過剰なコンパイルされたコードであるものは非常に多くあります。

どんなに小さなコードでもできる例：MenuetOS、1枚のフロッピーディスクに収まる強力なアプリを備えた完全な64ビットOS。

明らかな理由もなく大きなコードになる可能性がある例：「Hello、World！」という単純なテキスト出力を行いました。最近エイダで。コンパイルされた実行可能ファイルは1 MiB以上でした！アセンブリ内の同じ実行可能ファイルはKiBまたは2だけです（その大部分は実行可能オーバーヘッドであり、実際の実行コードは数十バイトです）。

ソフトウェアは、ユーザーと利用可能なハードウェアという2つの要素に適合するように構築する必要があることは自明です。ユーザーが自由に使用できるハードウェアを使用して、ユーザーが望むものをタイムリーに実行する場合、プログラムはその目的に適しています。まあ。しかし、基本的にすべての測定可能な次元でハードウェアが向上すると、不適合から適合に移行する個別のプログラムの数が増加します-設計スペースが大きくなります。

• 高レベルの言語を使用すると、以前よりも少ないコードと時間でアイデアを表現できます。逆に、この複雑さの低下により、ますます複雑なアイデアを表現することが可能になります。
• 同梱より多くのデータをアプリケーションにすると、すぐに使いやすくなります。たとえば、スペルチェックアプリケーションが人類に知られているすべての言語にバンドルされるようになるまで、おそらくそれほど長くはかからないでしょう。結局のところ、ほんの数ギガバイトです。
• ハードウェアのトレードオフにより、開発者とユーザーは、関心のあるリソースをより多く選択できます。たとえば、FLAC / OGG対WAV、SVG対PNG、データベースインデックスを参照してください。
• 人道的なインターフェイスは、以前はユーザビリティのために膨大な量のハードウェアに相当するものをしばしばトレードオフしました。アンチエイリアシング、高解像度、高速リフレッシュ、個別のパネルに至るまでのスワイプはすべて、よりリアルで直感的な、関連性のあるエクスペリエンスを実現します。

これは、Androidアプリケーションに関して間違いなく当てはまります。4年前、シンプルなアプリは約2〜5メガバイトのスペースを取りました。現在、シンプルなアプリは約10〜20メガバイトのスペースを必要とします。

使用可能なスペースが多いほど、アプリのサイズは大きくなります。

Androidの場合、主に2つの理由があると思います。

• GoogleはAndroidフレームワークを拡張し、多くの新しい機能を追加しました。

• 開発者はもう気にしません。画像ははるかに高い解像度（もちろんスマートフォンの画面解像度が向上）に含まれており、サードパーティのライブラリは軽率に含まれています。

その多くは、開発者の時間とその時間のコストに帰着します。Visual Basicが最初に登場した当時、C / C ++と競合しており、それに対する大きな打撃は、おそらくANSI C for Windowsで15Kで「Hello World」を記述できることでした。VBの問題は、常に300Kランタイムライブラリのアホウドリがいたことです。

これで、VBプログラムの10倍のサイズで、さらに数K増えますが、C / C ++プログラムの10倍のサイズで、さらに数か月の開発が見られます。

最終的には、アプリケーションの肥大化は、開発生産の大幅な飛躍、価格の低下、および手作業で開発された古い時代では不可能だった機能の大幅な拡張に支払う小さな価格です。プログラムが小さくて高速だったが、弱く、互いに互換性がなく、機能が不十分で、開発に費用がかかったとき。

時間の経過とともに、ユーザーのニーズは進化し、ますます要求が厳しくなります。そのため、さまざまなソフトウェアのベンダー/作成者は、競争の名の下でそれらのニーズを満たすことを余儀なくされています。

しかし、新しいニーズを満たすことは、多くの場合、新しいコードを追加することを意味します。新しいコードは、修正する新しい脆弱性を意味します。新しい脆弱性を修正すると、コードが追加されたり、新しい脆弱性への扉が開かれたりする可能性があります。

ユーザーのニーズを満たすために追加された各機能には、速度を上げるためにより多くのプロセッサパワーが必要になる場合があります（これまたはそのブラウザの速度について不平を言います）。

これはすべて、アプリケーション（コード）、セキュリティ、および場合によってはハードウェアの新しいレイヤーを追加することを意味します。

サイズの多くは、組み込みライブラリに由来します。最近の多くのアプリケーションは、アプリケーションに膨大な量の電子を使用して構築されています。Linuxにアプリケーションをインストールする場合、アプリケーションの多くは他のプログラムも使用している共有ライブラリを介して既にインストールされているため、通常ははるかに小さくなります。

ソフトウェアを構築するときに、機能Aが必要な場合は、モジュールA *をインポートします。A *はAを解くことができますが、A *はAよりも多くの問題を解くことができ、A *は大きくなる可能性があります。すべての大規模なモジュールは、大規模なソフトウェアになります。

同じケースではないかもしれませんが、次のようなものです。Javaを使用してコンソールに「hello world」を印刷するだけの場合は、JRE（> 60MB）がインストールされている必要があります。

Javaの例が適切でない場合は、これを試してください：ソフトウェアがファイルにログを記録する必要がある場合は、ネットワークおよびその他の機能を介してデータベースにログを実際に作成できるログモジュールを使用できますが、プロジェクト。

私は、プログラムがどれだけ多くのメモリを使用するかというルールについて読んでいますが、それはなぜですか？

それはまったく真実ではありません。システムは、オペレーティングシステムがメモリ不足になるまで、消費したメモリを解放しません。これはパフォーマンスの向上です。画像が表示されているページを閲覧している場合は、移動します。あなたは戻ってナビゲートするかもしれないので、再び画像が必要です。オペレーティングシステムにRAMが搭載されている場合、メモリが再び必要ないことが確実になるまでメモリをクリアしても意味がありません。

メモリをすぐにクリアすると、CPUサイクルとメモリ帯域幅がユーザーから奪われる可能性が高くなります。おそらく、ユーザーは、応答性の高いWebページを画面に表示したいと思うでしょう。

オペレーティングシステムは、利用可能なすべての非アプリケーションメモリを消費しますが、その大部分はファイルシステムキャッシュ用です。

メモリ管理は難しい問題ですが、非常に賢い人々が常にそれに取り組んでいます。意図的に無駄になるものはありません。主な目標は、非常に応答性の高いコンピューターを提供することです。

グリッドロックされたスーパーハイウェイに新しい車線を追加し、数年以内に交通が再びバックアップされる郊外の現象と同様に、プログラムは利用可能なスペースを埋めるように拡大する傾向があるのは事実かもしれません。

しかし、それを調べてみると、プログラムが実際にもっと多くのことをしていることがわかるかもしれません。たとえば、ブラウザは、より洗練されたグラフィックスを実行し、数年前には存在しなかった洗練された開発者ツールを備えています。また、コードのごく一部を使用して、多くのライブラリにリンクします。そのため、利用可能なメモリを埋めるためにプログラムのサイズが大きくなる場合がありますが、その一部は正当な理由である可能性があります。

最適化されていないオブジェクト上に構築されたライブラリは、ロード、インストールに必要なメモリが増え、操作に必要な計算サイクルが増えます。オブジェクトコードの大部分は肥大化しています。

実行中の標準C ++コードをステップ実行して、すべてのassert（）edオブジェクト呼び出しを確認し、それらが有効なオブジェクトであることを確認してください。オブジェクトをカプセル化するオブジェクトのレイヤー上にレイヤーを設計すると、下層は肥大化して不透明になります。プログラマは、必要な機能に制限されているものを再設計するよりも速いため、怠け者となり、より多くのオブジェクトを使用します。本当に簡単です。

Linux Cカーネルのサイズ、カーネルのみを考慮し、カスタムアプリケーションのサイズを考慮してください。カーネルはマシン全体を実行できます。しかし、アプリケーションほど速く構築されたわけではなく、最高の機能を実現するには時間がかかります。