メモリ不足はより効率的な効率的なプログラミングを促進するか？

短い回答：技術的能力よりもインセンティブ

メモリ不足の間にプログラマーがより効率的なコードを書くかどうかは、技術的な能力ではなく、ビジネス上のインセンティブに完全に依存します。超効率的なソフトウェアを書く能力は存在しますが、ほとんどの業界の専門家は、メモリ制約が市場投入までの時間（time-to-market）、コンバージョン率、またはハードウェアの売上高に直接影響を与えない限り、高レベルの抽象化と迅速なデリバリーサイクルによって引き起こされるソフトウェアの肥大化（bloat）の傾向は続くであろうと主張しています。

最適化におけるビジネスインセンティブの役割

最適化は、開発者が主導する取り組みであることは稀です。それはプロダクトオーナーの決定です。トレードオフは通常、ハードウェアコストと市場投入までの時間（time-to-market）の間で行われます。

市場投入までの時間の優先： 現在の「AIレース」において、速度は最優先事項です。多くの企業は「素早く動き、破壊せよ（move fast and break things）」という考え方を採用しており、そこでは開発者の時間のコストが、非効率なメモリ使用のコストを上回ります。
財務的指標： 最適化は、非効率性に対して明確な金銭的ペナルティがある場合に発生します。例えば、eコマースでは、ページ読み込みの100msの遅延がコンバージョン率の目に見える低下を招く可能性があり、パフォーマンスの向上を強制させます。
ハードウェアの制約： AAAゲームにおいて、コンソールの制限は絶対的な上限として機能します。開発者は、ゲームが可能な限り広い層のユーザーにプレイ可能であることを保証するために、最も低い共通項（例：Nintendo Switch）に合わせて最適化を行わなければなりません。

実際に最適化が行われている場所

一般的なアプリケーションソフトウェアは肥大化したままですが、特定のセクターは、極端なスケールや厳格なハードウェア制限のために、積極的にメモリ効率を追求しています。

ハイパースケーラーとクラウドインフラストラクチャ

大規模なデータセンターのスケールでは、わずかなメモリ削減が数百万ドルの節約につながります。クラウドコンピューティング、AIトレーニング、および大規模なデータ処理は、最適化がビジネス上の必要不可欠な要素となる主な領域です。

組み込みシステムと専門的な研究

粒子物理学のような分野では、「グリッドコンピューティング」がしばしば厳格な制限（例：1コアあたり2GB）を課します。これにより、開発者はスループットを維持するために、メモリへの適合やマルチスレッド化を優先せざるを得なくなります。同様に、ESP32のような低電力デバイスを対象とする開発者は、キロバイト単位のRAM制限内に収めるために、不要なバッファを排除せざるを得ません。

モバイルエコシステム

プラットフォームホルダー（GoogleやApple）は、効率性を促進する可能性が最も高い存在です。彼らはハードウェアとOSの両方を制御しているため、、アプリに対してより厳格なバックグラウンド制限を課したり、メモリの少ないハードウェア（例：8GB MacBook）をリリースしたりすることで、エコシステムに適応させることを強制できます。

「肥大化」の問題：抽象化 vs アルゴリズム

議論において繰り返し現れるテーマは、メモリの非効率性は、質の低いアルゴリズム（例：$O(N ext{ log } N)$ を $O(N)$ の代わりに使用すること）によって引き起こされるのではなく、むしろアーキテクチャの選択と抽象化によって引き起こされるということです。

フレームワークの過負荷： ElectronやChromiumを使用してウェブ技術をデスクトップアプリにまとめることは、肥大化の主な要因として挙げられており、ネイティブアプリがリソースのわずかな一部で処理できるタスクに対して、しばしば数ギガバイトのRAMを消費します。
言語の選択： 言語の選択は、ベースラインのメモリフットプリントに大きな影響を与えます。ある開発者は、Rustで構築されたユーティリティは450kbのバイナリとなり、同じユーティリティをHaskellで構築した場合、30mbのバイナリとなったと述べています。
複雑さの管理： 大規模なチームは、アーキテクチャの複雑さと、より細粒度のローディングシステムの複雑さや脆弱性に関連する問題を避けるため、必要かどうかにかかかわらず、多数のサブモジュールをロードします。

カウンタートレンド：AIの影響

逆説的ですが、同じAIトレンドがメモリ不足を引き起こしている一方で、ソフトウェアのメモリ消費を実際に増加させる可能性があります。大規模言語モデル（LLM）をアプリケーションに直接統合する動きが強まっており、これにはかなりのRAMが必要となるため、ポテンシャルとして、従来の最適化によって得られた利得を相殺してしまう可能性があります。

効率性を強制するための戦略

一部の実務家は、肥大化の傾向を逆転させる唯一の方法は、開発中に人工的な制約約を導入することであると示唆しています。

"The only way to make them to write efficient code is to force developers to do development and testing of the software on the weak machine."

他の開発者は、エンドユーザーの環境の現実を反映させるために、CI/CDパイプラインでリフレッシュされた古いハードウェアを使用することを提唱しており、それによって、高スペックの開発者用マシンでのみ見えないパフォーマンス・バグをキャッチすることができます。