記憶體短缺會推動更有效率的程式設計嗎？

簡短回答：激勵勝於技術能力

程式設計師在記憶體短缺時是否會寫出更有效率的程式碼，完全取決於商業激勵而非技術能力。雖然撰寫超高效能軟體的能力確實存在，但大多數產業專業人士認為，除非記憶體限制直接影響上市時間、轉換率或硬體銷售，否則由高階抽象與快速交付週期所推動的軟體膨脹趨勢將持續。

最佳化很少是由開發者主導的倡議；它通常是產品負責人的決策。權衡通常在硬體成本與上市時間之間。

上市時間優先：在當前的「AI 競賽」中，速度是首要目標。許多公司採取「快速行動、破壞舊有」的心態，開發者時間的成本超過了低效記憶體使用的成本。
財務指標：當低效能帶來明確的財務懲罰時，才會進行最佳化。例如在電子商務中，頁面載入延遲 100ms 可能導致可測量的轉換率下降，迫使提升效能。
硬體限制：在 AAA 遊戲中，主機的限制是硬性的上限。開發者必須針對最低公分母（例如 Nintendo Switch）進行最佳化，以確保遊戲能供最廣大的玩家群體遊玩。

雖然一般應用軟體仍然膨脹，但特定領域因規模極大或硬體限制嚴格，正積極追求記憶體效率。

在龐大資料中心的規模下，微小的記憶體減少可轉化為數百萬美元的節省。雲端運算、AI 訓練與大規模資料處理是最佳化成為商業必需的主要領域。

在粒子物理等領域，「網格運算」常設有嚴格限制（例如每核心 2GB）。這迫使開發者優先考慮記憶體適配或多執行緒以維持吞吐量。同樣地，針對低功耗裝置（如 ESP32）的開發者必須刪除不必要的緩衝區，以符合千位元組等級的 RAM 限制。

平台持有者（如 Google 與 Apple）最有可能推動效率。因為他們同時掌控硬體與作業系統，能對應用程式施加更嚴格的背景限制，或推出較低 RAM 的硬體（例如 8GB MacBook），迫使整個生態系統調整。

討論中反覆出現的主題是，記憶體低效很少是由於糟糕的演算法（例如使用 $O(N \log N)$ 而非 $O(N)$）所致，而是源於架構選擇與抽象層。

框架過載：使用 Electron 與 Chromium 將網頁技術打包成桌面應用被視為膨脹的主要原因，常會為本可由原生應用以極少資源完成的任務消耗數 GB 的 RAM。
語言選擇：程式語言的選擇會顯著影響基礎記憶體佔用。一位開發者指出，用 Rust 建置的工具只有 450kb 的二進位檔，而相同工具用 Haskell 則產生 30mb 的二進位檔。
複雜度管理：大型團隊常會載入大量子模組，即使不需要，以避免更細粒度載入系統所帶來的架構複雜性與脆弱性。

矛盾的是，同樣導致記憶體短缺的 AI 趨勢可能實際上會提升軟體的記憶體消耗。業界正大力將大型語言模型（LLM）直接整合至應用程式中，這需要大量 RAM，可能抵消傳統最佳化所帶來的效益。

一些實務者認為，唯一能扭轉膨脹趨勢的方式是於開發階段加入人為限制：

「唯一讓他們寫出有效率程式碼的方式，就是強迫開發者在弱機上進行軟體的開發與測試。」

其他開發者則主張在 CI/CD 流程中使用翻新或較舊的硬體，以映射最終使用者環境的實際情況，捕捉在高規格開發機上看不見的效能漏洞。