“软件变慢的速度，比硬件变快的速度更快。”

开发者硬件 vs. 用户现实

• 许多人认为，开发者应该定期使用低端机器，或使用被限制到“第 5 百分位”规格的虚拟机，这样才能切身体会真实用户的痛点，并优先关注性能。
• 也有人认为这适得其反：现代开发栈（IDE、Docker、数据库、Node 等）本身就会拖慢好机器；故意降低硬件速度只是在浪费开发者昂贵的时间。
• 建议的折中方案是：开发机保持高速，但把产品本身放到受限的虚拟机/手机里运行，或使用专门的低配测试机器。

性能 vs 功能与商业激励

• 一个反复出现的主题是：决定优先级的是企业，而不是开发者；功能和期限几乎总是压过性能。
• 用户往往更想要新能力而不是速度，尤其是当某个功能能节省数天，而性能提升只能节省数小时的时候。
• 有人担心这像杰文斯悖论：效率提升最终只会被花在更多功能和更多层次上，而不是更好的响应速度。

慢从哪里来

• 经常被提到的元凶包括：臃肿的 Web、Electron 应用、过多框架、SaaS/网络往返、数据库 N+1 查询、缺失索引，以及过度抽象的架构。
• 也有人指出，在企业环境中，“自研东西”往往比选用合适且高效的现成组件更糟。
• 安全工具、遥测，以及“企业软件”被描述为 I/O 和 CPU 的主要消耗者。

维尔特定律真的成立吗？

• 有些人说是：日常应用、UI 和简单操作即便硬件提升了几个数量级，也往往感觉并没有快多少；他们举出输入延迟和慢手机的例子。
• 也有人用轶事反驳，称便宜的现代机器比 2000 年代中期的 PC 快得多，尤其是在 SSD 和更好的网络条件下。
• 还有几位提到，缺乏严格的纵向测量；大多数证据都只是轶事。

优化文化与语言

• 有人觉得“优化是万恶之源”这句话被误用成了永远不优化的借口，而许多团队甚至根本不会做 profiling 或测量。
• 也有人认为，优化在真正重要的地方仍然受到重视（如游戏、数据工具、以及更快的 Python 生态等注重性能的库），但商业论证往往不够强。
• 这条讨论串强调了经典的性能提升：更好的数据库查询、索引、更少的网络调用，以及避免不必要的抽象层。

未来方向与工具

• 人们建议使用网络/CPU 限速工具、在慢硬件上跑 CI，以及使用真实数据集，作为保持性能在可控范围内的实用方法。
• 对于 AI 生成代码会不会让臃肿问题更严重（更快产出“能用但很慢”的代码），还是会帮助优化，大家看法不一，这取决于它的使用方式。