内存短缺会推动更高效的编程吗？

简短的回答：激励机制重于技术能力

程序员在内存短缺期间是否会编写更高效的代码，完全取决于业务激励，而非技术能力。虽然编写超高效软件的能力是存在的，但大多数行业专业人士认为，除非内存限制直接影响产品上市时间、转化率或硬件销售，否则由高级抽象和快速交付周期驱动的软件膨胀趋势将会持续。

优化很少是由开发者主导的倡议；它通常是产品所有者的决策。权衡通常是在硬件成本和产品上市时间之间进行的。

产品上市时间优先： 在当前的“AI 竞赛”中，速度是首要任务。许多公司采取“快速行动，打破常规”的心态，在这种心态下，开发者时间成本超过了低效内存使用的成本。
财务指标： 当低效行为带来明确的财务惩罚时，优化才会发生。例如，在电子商务领域，页面加载延迟 100 毫秒可能会导致转化率的可衡量下降，从而迫使人们追求性能。
硬件限制： 在 AAA 级游戏中，主机限制充当了硬性上限。开发者必须针对最低公分母（例如，Nintendo Switch）进行优化，以确保游戏能为尽可能广泛的受众所玩。

虽然通用应用程序软件仍然臃肿，但由于极端的规模或严格的硬件限制，特定领域正在积极追求内存效率。

在海量数据中心的规模下，微小的内存减少可以转化为数百万美元的节省。云计算、AI 训练和大规模数据处理是优化成为业务必需品的主要领域。

在粒子物理学等领域，“网格计算”通常会施加严格的限制（例如，每个核心 2GB）。这迫使开发者优先考虑内存适配或多线程处理以维持吞吐量。同样，针对 ESP32 等低功耗设备的开发者被迫消除不必要的缓冲区，以适应千字节级的 RAM 限制。

平台持有者（如 Google 和 Apple）最有可能推动效率。因为他们同时控制着硬件和操作系统，他们可以对应用施加更严格的后台限制，或者发布低 RAM 的硬件（例如，8GB MacBooks），从而迫使生态系统进行适配。

讨论中一个反复出现的主题是，内存低效很少是由糟糕的算法（例如，使用 $O(N ext{ log } N)$ 而不是 $O(N)$）引起的，而是由架构选择和抽象引起的。

框架过载： 使用 Electron 和 Chromium 将 Web 技术打包进桌面应用被认为是膨胀的主要驱动因素，通常为原生应用只需一小部分资源即可处理的任务消耗数 GB 的 RAM。
语言选择： 语言的选择会显著影响基准内存占用。一位开发者指出，用 Rust 构建的工具程序二进制文件仅为 450kb，而用 Haskell 构建的相同工具程序二进制文件则为 30mb。
复杂度管理： 大型团队通常会加载大量子模块，无论是否需要，以避免与更细粒度的加载系统相关的架构复杂性和脆弱性。

矛盾的是，导致内存短缺的同一种 AI 趋势可能会实际上增加软件的内存消耗。目前正有一种强烈的趋势将大语言模型 (LLMs) 直接集成到应用程序中，这需要大量的 RAM，可能会抵消通过传统优化所取得的任何收益。

一些从业者建议，扭转膨胀趋势的唯一方法是在开发过程中引入人为约束：

"只有通过迫使开发者在性能较弱的机器上进行软件的开发和测试，才能让他们编写出高效的代码。"

其他开发者主张使用翻新的旧硬件用于 CI/CD 流水线，以模拟终端用户的环境现实，从而捕捉在高规格开发机上无法察觉的性能缺陷。