perf

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Measure before you change code for speed. A claim about speed without a measurement is only a guess. A change that rests on a guess can make the code slower.

Fast path: when the user only asks whether a measured number holds, change no code. Read the

verify

skill, and check the number with measurement.md. When the user asks only why code is slow, or gives a profile or trace file, also change no code. Go to step 4, and report as its reference says.

Before you measure anything, create a task list with these steps as its items. If a task list already exists, add the steps to it. When you skip a step, mark it done and add
```
skip: <reason>
```
to its text. To go back to an earlier step, add that step and each step after it again as new items.
State the target in one sentence: the operation, the input, and the number that counts as success. Take the target from the user or the spec. When nobody gave one, the target is a gain larger than the spread on a realistic input. Say so.
Build a measurement that you can run again: a script or a command, and a realistic input. Run each side five times or more. Check the measurement with measurement.md before you trust it. Step 4 answers its first check. Record the baseline: the number, its unit, the run count, and the spread.
Find the limiter, the one resource that stops the number from getting better, by observation. Do not guess it from the source. Use a profiler, a trace, or counters. A profiler slows the work, so never report a number from a profiled run. For a running process, follow live-process.md. For a profile, trace, dump, or log file that already exists, follow capture-file.md.
Change one thing at the limiter, and try the cheapest kind of change first. First remove work whose result nothing uses. Then do the work once, and keep the result. Then do less work. Then do the work later. Then do it at a time when nobody waits. Then run it in parallel. Make the work itself cheaper only as the last option. A change that keeps results, delays work, or runs work in parallel can change behavior. Give it a failing test first, as implement says.
Measure again with the same setup, and run the old and new versions in alternating order. Run the tests that exercise the changed path. Keep the change only when they pass and the gain is larger than the spread. Otherwise revert it. When a kept change meets the target, go to step 7. Otherwise go back to step 4.
Before you report the gain, read the
```
verify
```
skill, and follow it for the tests, the build, and the linter. The measurement script is a demo of the gain, as verify defines a demo. Report the gain as a measured number, not as a verified criterion.
Report the result: the number before and after, each with its unit, run count, spread, and limiter. Name the change and the input that you measured.

Rules:

Change no code for speed before the baseline exists.
Make one change between two measurements, so that each gain has one cause.
A request for a diagnosis gets a diagnosis, not a fix. Cite the evidence for each finding.
A deadlock, a crash, or a wrong result is a defect, not slowness. Its fix goes to
```
debug
```
.
Do not tune code that the measurement does not show as the limiter.
Stop after three changes in a row that give no gain larger than the spread. Report the measurements and the limiter, and let the user decide.
When the work continues after the session, keep the measurement script in the diff, as implement's build-the-lever principle says.
Never invent a number. Report a measurement that failed as failed.
A raw payload that you must read, and that is longer than about 2,000 lines, goes to a subagent. Keep only the reduced finding in the session, as research's guard-the-context-window principle says.

在为了提速而修改代码之前，先进行测量。任何没有测量支撑的速度声明都只是猜测。建立在猜测之上的改动可能让代码更慢。

快速路径：当用户只是询问某个测量数值是否成立时，不要修改代码。阅读

verify

skill，并按照 measurement.md 检查该数值。当用户只是询问代码为何缓慢，或提供了 profile 或 trace 文件时，同样不要修改代码。转到第 4 步，并按照该步骤引用的文档所述进行报告。

在测量任何内容之前，以这些步骤为条目创建任务列表。如果已有任务列表，则将这些步骤加入其中。跳过某一步时，将其标记为已完成，并在其文本中添加
```
skip: <reason>
```
。如需返回之前的步骤，则将该步骤及其后的每一步再次作为新条目添加。
用一句话说明目标：要执行的操作、输入，以及视为成功的数值。目标应来自用户或规范。如果没有人给出目标，则将目标设为：在贴近实际的输入上取得大于波动范围的提升，并明确说明这一点。
构建可重复运行的测量方案：一个脚本或命令，以及一份贴近实际的输入。每个被测方案至少运行 5 次或更多。在信任测量结果前，按照 measurement.md 检查该测量。第 4 步会回答其中的第一项检查。记录基线：数值、单位、运行次数和波动范围。
通过观察找出限制因素，即阻止数值继续改善的单一资源。不要根据源代码猜测。使用 profiler、trace 或 counters。profiler 会拖慢工作，因此绝不能报告来自 profiler 运行过程的数值。对于正在运行的进程，请遵循 live-process.md。对于已经存在的 profile、trace、dump 或 log 文件，请遵循 capture-file.md。
在限制因素处一次只改一个地方，并优先尝试成本最低的改动。首先，删除结果无人使用的工作。然后，只执行一次该工作并保留结果。接着，减少工作量。然后，推迟该工作。然后，在无人等待时执行该工作。然后，并行运行该工作。最后，才考虑让工作本身变得更廉价。保留结果、推迟工作或并行运行工作的改动可能改变行为。按照
```
implement
```
的要求，应先为它编写一个会失败的测试。
使用相同的设置再次测量，并交替运行旧版本和新版本。运行覆盖改动路径的测试。只有当测试通过且收益大于波动范围时，才保留改动；否则回退。如果保留的改动达到目标，转到第 7 步；否则返回第 4 步。
在报告收益之前，阅读
```
verify
```
skill，并按照它执行测试、构建和 linter 检查。按照
```
verify
```
对 demo 的定义，测量脚本只是收益的 demo。将收益报告为测量所得的数值，而不是经过验证的判据。
报告结果：改动前和改动后的数值、各自的单位、运行次数、波动范围和限制因素。说明所做的改动以及用于测量的输入。

规则：

在基线建立之前，不要为提速修改代码。
两次测量之间只做一项改动，使每项收益只有一个原因。
诊断请求应得到诊断，而不是修复。为每项结论引用证据。
死锁、崩溃或错误结果是缺陷，而不是缓慢。其修复应转交
```
debug
```
。
不要调整测量未表明为限制因素的代码。
连续三次改动都没有带来大于波动范围的收益时停止。报告测量结果和限制因素，由用户决定。
如果工作会在本次会话结束后继续，则按照
```
implement
```
的 build-the-lever 原则，将测量脚本保留在 diff 中。
绝不编造数值。测量失败时，应如实报告为失败。
对于必须阅读且超过约 2,000 行的原始 payload，将其交给 subagent。按照
```
research
```
的 guard-the-context-window 原则，会话中只保留精简后的结论。