你对慢的直觉通常是错的

一个医生凭猜测就开出手术方案，从没做过检查——自信、迅速，却常常在错误的地方动刀。

开发者在「时间花到哪儿去了」这件事上，出了名地爱猜错。你确信很慢的那部分，往往没问题；真正的元凶在你从没怀疑过的地方——一个被调用了上百万次的小函数，一次藏起来的数据库调用。

凭直觉行动，意味着你优化了错的东西，添了复杂度，而程序依旧很慢。第一步从来不是「修它」——而是弄清楚时间到底花在了哪儿。

地图：七组共 20 个概念

一张地铁线路图：先看见完整的线路，再一站一站地坐过去。

这门课的概念分成七组——每章一组。先讲怎么测量。再讲你要的是哪种「快」。然后是 bottleneck 和对付它的经典办法。最后讲如何不被平均值骗，什么时候不该优化，以及怎么把整件事当作一个循环来跑。

怎么读这门课

修车师傅不会随手乱换零件：先上仪器，再修一处，再复测。

每个概念都享受同样的待遇：它的英文名（记住它——文档、profiler 和仪表盘里用的就是这个词）、一幅日常生活的画面、一张图，以及一张卡片，上面有是什么、怎么运作、例子、陷阱和关联。

大想法：性能不是一袋小技巧，而是一套方法。测量 → 找到 bottleneck → 只修那一个 → 再测一遍 → 达到目标就停。 课里其余的一切，都是这个循环里的细节。

Profiling — 找出真正的开销

一张逐项列出的账单，一行一行地告诉你钱到底花在了哪儿——于是你不再瞎猜，而是看到吃掉预算的是那一笔，而不是你以为的那些。

Profiler 是一种工具，它测量你的程序到底把时间花在哪儿，细到每个函数。它把「我觉得这个慢」变成「这一个函数占了 80% 的运行时间」。有了它，你修的是真正要紧的东西，而不是你想象出来的东西。

不管是 profiler、计时日志，还是你的**可观测性（observability）**指标，原则都一样：让测量，而不是直觉，把你指向问题。

Measure–Fix–Measure — 测量、修复、再测量

科学家只改一个变量，重做实验，再检查结果——从不假定改动有效，总是确认它真的有效。

性能是一个循环：先测量找到慢的部分，改它，然后再测一遍，确认这次改动真的有帮助——而不是只把问题挪了个地方，或者让它更糟。

没有第二次测量，你就只是在猜自己到底有没有改善，而这正是「优化」悄悄让东西变慢的原因。把每一次修复都当作一个要验证的假设——和 AI 的 evals、代码的测试是同一种纪律。

Latency — 等一件事的时间

一杯咖啡从下单到端到手里要多久——一位顾客的体验，从头量到尾。

Latency 是一次操作从开始到结束要多久——一个请求、一次页面加载、一条查询。它是单个用户感受到的东西：等待。

当有人说「网站很慢」，他几乎总是指 latency——做了一件事到拿到响应之间的延迟。降低 latency，就是让每一件事本身都发生得更快。

Throughput — 每秒能处理多少

整家咖啡馆一小时能出多少杯咖啡——不是一杯要多久，而是整个店里的总流量。

Throughput 是系统在单位时间内处理多少工作——每秒多少个请求，每分钟多少个任务。它说的是总容量，而不是个体的等待。

一个系统可以有很棒的 throughput（同时服务成千上万人），而每个用户仍要等一会儿（latency 高）；也可以 latency 很低，但容量有限。它们是不同的目标，你追的是哪一个，决定了你该修什么。

Batching — 用 latency 换 throughput

摩托车把一个人送到最快（低 latency）；公交车一趟运的人最多（高 throughput）。哪种车最好，取决于你要什么。

Latency 和 throughput 是相互独立的，优化其中一个可能伤到另一个。Batching——把工作攒在一起处理——通常会提高 throughput，却增加 latency，因为每一项都要等那一批凑齐。

所以你得决定这里哪个更重要：面向用户的页面，生死取决于 latency；后台的数据流水线，在乎的是 throughput。说清你真正的目标，能让你不去优化那个对用户无关紧要的数字。

Bottleneck — 一个慢的部分说了算

一条链子的强度，恰好等于它最弱的那一环——加固强的环毫无用处；能不能撑住，只由最弱的那一环决定。

在大多数慢的系统里，单独一个 bottleneck 就占掉了大部分时间——一条查询、一个慢服务、一个糟糕的循环。其余的部分本来就已经够快了。

这就是为什么猜测如此浪费：整门手艺就在于找到占大头的开销，而不是去改善那些本来就快的部分。

Limiting Step — 系统只能和它最慢的一步一样快

一条一路畅通的高速公路，直到某处封了一条车道，所有车都在龟速爬行——整趟路程的速度由那一个堵点决定，而不是那些畅通的路段。

一个要经过十个步骤的请求，受限于其中最慢的一步——即 limiting step。把另外九个快的步骤再提速，总时间几乎不动；慢的那一步决定了节奏。所以你要专门对准那个堵点。

还要注意：修好一个 bottleneck，常常会暴露出下一个：去掉最慢的一步，新的最慢一步就冒出来了。性能工作，就是不断找到并清除此刻正在限制系统的那个东西。

Amdahl's Law — 去优化别处是白费力气

车子爆了胎，你却在给奖杯抛光——力气花在了毫无改变的地方，而真正拦住你的东西被晾在一边。

优化一个只占运行时间 2% 的部分，你最多只能赢得 2%。找到那个占 80% 的部分，修好它就能改变一切。这道算术叫作 Amdahl 定律：你的收益，被你所加速的那部分实际占的时间份额封顶。

把时间花在优化 bottleneck 以外的任何东西上，按定义就是帮不上多大忙的时间。它常常还会把事情变糟，为一个看不见的收益添上复杂度和 bug。测量让你不再满怀爱意地优化自己看得懂的那一部分，而是逼你去处理真正花钱的那一部分。修好 bottleneck，别管其余——直到其余的变成了 bottleneck。

Better Algorithm (Big-O) — 好算法胜过快机器

去同一座城市的两条路：一辆更快的车走又长又绕的路，仍然输给一辆更慢的车走笔直的捷径。路线比发动机更重要。

最大的提速，往往来自更好的算法或数据结构，而不是更快的硬件或微调。Big-O 描述输入变大时时间如何增长。把一个 O(n²) 的循环换成 O(n) 的哈希表查找，可以把几分钟变成几毫秒——再快的机器也比不上这样的改变。

在优化那些小东西之前，先问问是不是思路本身就错了。正如数据结构课所讲的，更好的形态是最便宜、也最大的提速。

N+1 Query — 往返次数太多

为了买东西，一趟只买一样，跑了二十趟商店，而不是拿着清单去一次——吃掉你下午的是路上的奔波，而不是购物本身。

大量的慢，其实是往返次数太多——对数据库或服务反复调用，每次单独看都很便宜，成批累积起来却是灾难。

经典的就是 N+1 查询：先取一个列表，然后对每一项再多发一条查询，把一次往返变成了几百次。修法是批量获取——一次把所有东西都要来。减少往返的次数，通常胜过加快每一次，因为往返本身就是开销。

Caching — 别把同一件事算两遍

每次有人点菜，都从头重新做一遍，而不是留一锅热着的——最快的活，就是不用重复的活。

Caching——把昂贵的结果记住，这样就不用重新计算——是最大的杠杆之一（它有自己专门的一门课）。

第一次请求走慢路径并把结果存下来；之后的请求直接从内存里拿。代价是内存，以及可能返回过期数据的风险。

Doing Less — 最快的活，是你跳过的活

没人点的菜就不做，来了三个人就别摆二十个人的餐桌。

还有一个经典办法——少做事。**惰性（lazily）**地计算，只在真正需要时才算；避免加载你用不上的数据；跳过那些结果最后要被扔掉的工作。

最快的操作，就是你从不运行的那个。往往最好的优化不是把活干得更快，而是压根不干。

Average — 平均值会藏住慢的情况

一个房间里，九个人很舒服，一个人身上着了火，平均温度却很宜人——平均数抹掉了真正要紧的那种情况。

把性能报告成平均值（mean），危险地让人安心：它把快的大多数和慢的少数搅成一个皆大欢喜的数字。可用户感受的不是平均值——每个用户经历的是他自己的那个请求，慢的那些，每一毫秒都感受得到。

平均 200 ms 的响应时间，可能藏着这样一个事实：二十个用户里有一个要等五秒。平均值告诉你系统没问题，而你有真实的一部分用户正在受苦。

Percentiles — p50 与 p99 才显示真实体验

一份报告说的不只是典型的等待时间，还有「最慢的 1% 的人等了这么久」——把糟糕的体验点名说出来，而不是把它们平均掉。

**Percentile（百分位数）**抓住了平均值藏起来的东西。p50（中位数）是典型情况——一半的请求比它快。p99 是慢的尾部——99% 的请求比它快，所以它大致就是真实用户会碰上的最糟体验。

盯着 p99，而不只是平均值，你才能看到那些真正在受苦的用户。痛苦就住在尾巴里，而 percentile 就是让它看得见的办法。

Tail Latency — 用户记住的是什么

在一家餐厅吃到一顿糟糕的饭，在人的记忆里，比十几顿还不错的饭分量更重——塑造别人如何评判你的，是最糟的体验，而不是平均值。

那些慢的请求——也就是 tail latency——不成比例地塑造了用户对你产品的观感，因为糟糕的体验会让人记住。

而且在大规模下，尾巴影响的人比看上去的要多：如果每个页面都要发出许多调用，至少有一个慢的概率就会飞快上升，所以几乎每个用户最终都会感受到尾巴。这就是为什么认真的团队把目标设在 p99 上，而不是平均值：驯服最糟的那些情况，才让一个产品感觉上稳定地快。

Premature Optimization — 万恶之源

为一场也许永远不会来的地震，把一座房子的每面墙都加固一遍，而这时还没有人搬进来——大把力气花在一个你还没有的问题上。

Donald Knuth 的那句名言——「过早优化是万恶之源」——警告的是：在你还不知道什么需要优化、或者到底有没有东西需要优化之前，就动手优化。

优化并不慢、甚至没怎么被运行的代码，什么也买不到，却花费不菲：复杂度、bug，以及从要紧事上偷走的时间。大多数代码不需要快；它需要正确而清晰。提速的工作，是留给测量证明为**热点（hot）**的那些部分的。

Correct → Clear → Fast — 先正确、清晰，在要紧处再求快

你把菜谱写得人人都能照着做，只把你一天做上一百次的那一步简化——不是每一步，只是热的那一步。

顺序是：先让它正确，再让它清晰，并且只在测量显示要紧的地方才让它变快。

清晰的代码，恰恰因为你看得懂，之后才更容易优化；当真正的 bottleneck 出现在别处时，纠缠成一团的「快」代码很难修。为速度而优化几乎总要牺牲可读性，所以你只在能换来真实、可测的收益的地方付出这个代价——其余的保持简单。

Performance by Design — 但在设计里也别无视性能

你不会给一间棚屋做抗震，但你也不会在沙地上盖摩天大楼——有些选择，早期做对很便宜，晚期再修则代价惨重。

这个警告并不是「别去想性能」。在 O(n) 同样容易的时候选了 O(n²) 的算法，或者选了一个撑不住规模的结构，是你日后要付大价钱的设计错误。

平衡点是：不要早早地做微观优化，但也别做出那种一开始就慢、日后又很贵才能撤销的架构选择。一开始就便宜地把大的形状做对；细节只在测量要求时才去优化。

Optimization Loop — 测量，修 bottleneck，重复

修车师傅用仪器诊断，修那一个坏掉的零件，再复测——从不乱换零件，指望噪音自己消失。

方法简单而有纪律：测量以找到 bottleneck，修那一个，再测一遍来确认并暴露出下一个 bottleneck，够快了就停。

每一轮都瞄准当前占大头的开销，无视其余的一切。这个循环让性能工作保持诚实而高效——你总知道自己在做的是真正要紧的事，也总知道自己有没有帮上忙。

Performance Target — 定个目标，然后收手

你给房子做保温，做到够暖和就停——不会一直往里加保温层，加到没人感觉得到的地步。

性能没有天然的终点——你总能把什么东西再弄快一点点。所以要定一个 performance target（「页面在 p99 下低于 300 ms」），达到了就停。

没有目标，优化就会变成一个收益递减、没完没了的时间黑洞，复杂度也会为没人注意到的收益悄悄混进来。知道「够快」对你的用户、你的场景意味着什么，才让你做刚刚好的性能工作，然后去建点别的东西。

整体是怎么拼在一起的

整条路线在一张地图上：你从哪儿出发，经过哪些站，在哪儿下车。

这些概念拼成一幅图。Profiling 找到 bottleneck；目标——latency 还是 throughput——告诉你该修什么。Bottleneck 通常由四个经典办法之一治好：更好的算法、更少的往返、缓存，或者少做事。然后你再测一遍，按 percentile，对照一个目标，然后收手。而过早优化，就是你跳过测量时发生的事。