知识卡片
性能优化必须用量化数据说话:拒绝说不清楚"提升了多少"的炫技式优化
内容
面试者谈到程序优化时,经常喜欢提一些听起来很专业的术语——调用栈、尾递归、内联函数、GC调优,但一旦追问具体细节,比如”把一个普通函数改成内联函数,原来运行速度是多少的程序会被优化成多少”,往往答不上来;进一步追问”这个函数会被调用多少遍、每遍耗时多长”这类支撑量化判断所必需的基础信息时,同样答不上来——这暴露出一个普遍现象:很多人谈论”性能优化”时停留在术语层面,却从未真正建立起”这项具体的优化手段,在这个具体的场景下到底能带来多大收益”这种量化思维。基于这个观察,给出的核心建议是:性能优化之后必须有量化数据支撑,明确说出优化后具体哪个指标提升了多少;如果有人以”提升性能”为理由,写出了一堆让人难以理解的复杂代码,务必要求对方给出具体的性能数据来证明这份复杂度的付出是值得的——因为这很有可能只是一堆没有实际收益的、以优化为名的烂代码。这条原则和[[评价性能优化是否合理:让作者说清瓶颈和收益,用数据说话而非单纯看代码]]是一脉相承的,但这里更进一步地指出了识别”伪优化”的具体方法:真正做过认真分析、确实带来收益的优化,作者一定能说清楚优化前后的具体数字对比;而那些只是套用了”听起来很厉害”的优化术语、实际上没有经过真正量化分析的改动,作者往往在被追问具体收益数字时会露出破绽——这个”能不能说清楚具体提升了多少”的追问,本身就是一个简单有效的筛选器,能够快速区分出真正有价值的性能优化和只是为了显得”技术含量高”而增加复杂度的伪优化。
参考来源
- 位置:《高可用架构(第1卷)》第5章《运维保障》"5.7 系统运维之如何应对烂代码"节,"5.7.2 改善性能与健壮性"(源文件:_epub-src/OEBPS/Text/Chapter5_7_3.xhtml)
- 结论依据:原文说明"我现在遇到的很多面试者在谈到程序优化时总是喜欢说一些玄乎的东西:调用栈、尾递归、内联函数、GC调优……但是当我问他们……却很少有人答出来……性能优化之后要有量化数据,明确说出优化后哪个指标提升了多少。如果有人因为'提升性能'之类的理由写了一堆让人无法理解的代码,请务必让他给出性能数据……因为这很有可能是一堆没有什么收益的烂代码",直接支撑本卡片结论。
- 原始内容:性能优化之后要有量化数据,明确说出优化后哪个指标提升了多少。如果有人因为"提升性能"之类的理由写了一堆让人无法理解的代码,请务必让他给出性能数据……因为这很有可能是一堆没有什么收益的烂代码。