内容摘要
Casey 的核心观点是：性能不是事后修热点，而是事前理解硬件上限、避免架构性失误。读汇编、怀疑教条、保留工程师自主性，比迷信某种语言、流程或 AI 工具更重要。
关键观点
真正的优化起点是理论上限，不是热点统计
Casey 直接否定了常见的“profile 一下、找大头、调一调、再看统计”的优化叙事。他认为那更像局部改良，而不是严格意义上的优化。真正的方法是先拆出系统必须执行的操作，再估算底层硬件的理论峰值，随后测量现状与上限之间的差距。这样做的价值不只是为了更快，也是在建立一个可解释的性能模型，避免团队把偶然改善误判成根因解决。
为什么重要: 这会改变团队的性能工作方式：从被动修补转向主动建模。没有上限意识，很多“优化成果”只是停在局部最优。
支撑证据
the correct way to do optimization is very much like what you just said you first go what are the operations that this system has to perform form. What is the underlying hardware capable of doing at its theoretical peak? And then you measure the delta between that theoretical maximum and what you have achieved.
多数严重性能问题是架构问题，后期专家救不了
Casey 反复强调，许多性能灾难不是某个函数慢，而是系统从一开始就被写成了难以优化的形状。最典型的例子是伪串行依赖：请求服务器、等待、计算、再请求、再等待。这样的依赖链天然不能并行，后期几乎只能重写，而不是“优化”。这也解释了为什么很多公司最后不是修热点，而是重写系统或改语言。