第25章：代码调整策略
第25章：代码调整策略：从‘感觉更快’推进到‘热点、收益和质量取舍可复核’，以固定基线、单点改变和统计复测裁决调整。
学习目标
- 能定义可接受的性能目标、固定负载和基线记录，并解释为什么它们必须同时保持不变。
- 能定位真实热点，只改变一个候选机制，用分布、正确性和质量代价判断是否接受调整。
- 能回答：当一次最快结果与尾部延迟、可读性或可移植性冲突时，应该保留哪些证据再做决定？
为什么代码调整要从证据开始
想象两条同样长度的路：一条偶尔很快，却常常堵车；另一条每次都稳定。只看一次最快抵达，就会选错路。代码调整解决的正是这个问题：先把“快”说成可检查的目标，再比较多次运行的结果。
如果没有这套记录，改动可能只是换了输入、缓存或机器状态；代码看起来更聪明，用户却承担了更高的尾部延迟、更多内存或更难维护的分支。本章把“调整”收束为一条能回退、能重放、能解释的证据链。
学习合同：目标、基线与裁决
用同一版本、同一输入和同一观察窗口比较基线与候选：
这个式子在说：只有候选与基线的计时条件一致，速度提升才有意义；还要同时记录错误率、内存、尾部延迟和可读性代价。
先写 ↡在给定负载下声明延迟、吞吐、资源和可接受回归边界的验收条件，再做 ↡用固定版本、输入、环境和观察窗口记录多次运行分布的参考测量。分析器找到最值得解释的 ↡在真实负载中占用主要时间或资源、值得优先验证的执行区域 后，才选择一个 ↡只改变一个机制并保持正确性合同不变的可回退改动。最后用 ↡交替运行基线与候选并比较中位数、尾部和回归的重复测量 检查收益；把收益、风险和维护成本放在同一张表里，完成 ↡在速度、资源、正确性、可读性与可移植性之间明确取舍的决策。
猜一猜：如果只把一次运行的最好值写进报告，切换到边界负载后哪一个节点最先失去证据？先在下面的实验中选一个场景，再说明你的预测。
第25章 · 证据链实验
性能目标 → 基线测量 → 热点定位 → 候选调整 → 统计复测
先猜哪一个节点会先偏离，再切换负载或注入故障；最后重置并用同一输入确认轨迹。
选择场景观察首个偏离；点击“重置实验”后，必须回到固定基线，才算完成一次可复核调整。
目录节点到可复核证据
下面每个节点都对应一个具体判断：它改变了什么、需要看什么数据、何时应该停止调整。这样目录不是关键词清单，而是可回收的实验路线。
第25章 代码调整策略
第25章 代码调整策略的主线不是“把代码写得更机巧”，而是让调整成为受合同约束的实验。先保存输入、版本、环境和验收阈值，再把每一次改动绑定到一个可解释的热点，最后保留接受或回退的理由。
25.1 性能概述
25.1 性能概述要求先区分速度、吞吐、内存和尾部延迟。若目标只写“更快”，就无法知道哪个回归是不可接受的；目标必须能落成指标、负载和观察窗口三项记录。
质量特性和性能
质量特性和性能不是把所有指标平均成一个分数。一次调整可能降低平均耗时，却增加错误率或峰值内存；报告要把正确性、稳定性、资源和可维护性并列展示，再说明哪个约束具有优先级。
性能和代码调整
性能和代码调整的关系是“测量先于修改”，不是“修改后寻找证明”。只有真实负载中的热点才值得投入复杂度；非热点的局部聪明写法即使在微基准中变快，也可能没有用户可见收益。
25.2 代码调整简介
25.2 代码调整简介把流程拆为目标、基线、热点、候选和复测五步。每一步都留下输入和输出，下一步不能偷偷改变前提；一旦首个偏离无法解释，就回到最近的稳定节点。
Pareto法则
Pareto法则在这里是一个寻找线索的启发：少数路径常贡献大部分时间，但它不是自动接受改动的理由。先用测量确认热点，再检查低频路径的错误和边界，避免把“可能重要”当成“已经证明”。
一些无稽之谈
一些无稽之谈包括“聪明的代码必然更快”“编译器优化后无需测量”和“最快的一次就是典型表现”。把这些说法改写成可反驳的预测，再用固定输入和重复样本检验，错误就能被证据而不是争论淘汰。
何时调整代码
何时调整代码取决于目标是否明确、热点是否稳定和收益是否足以支付复杂度。刚修复正确性、负载还在变化或测量噪声很大时，应先建立可重复基线，而不是急着加一个微优化。
编译器优化
编译器优化会改变机器码、内联和布局，但不会替开发者声明业务约束。比较编译器选项时固定编译器版本和输入，检查生成结果是否仍符合正确性、可移植性与调试要求，不能把黑箱速度当成因果解释。
25.3 蜜糖和哥斯拉
25.3 蜜糖和哥斯拉提醒我们：小巧的语法糖可能隐藏分配、分支或调用，而极端的手工改写又可能制造难以维护的“哥斯拉”。用同一基线比较可读写法与低级写法，只有收益稳定且成本可接受时才保留。
常见的低效率之源
常见的低效率之源包括重复计算、错误的数据结构、过多分配、无效 I/O 和不必要的转换。列出来源后再测量占比，先处理最高影响且风险可控的一项；不要凭经验把所有可疑代码一起改掉。
常见操作的相对效率
常见操作的相对效率只能作为候选排序的背景数据。不同硬件、编译器、数据规模和缓存状态会改变相对次序，因此应把公开资料当作假设的起点，回到本项目的真实负载中复测。
25.4 性能测量
25.4 性能测量至少要记录样本数、预热方式、输入规模、编译参数、机器状态和时间单位。基线与候选应交替运行，避免先跑完一组后被温度、频率或后台任务误导。
性能测量应当精确
性能测量应当精确并不等于把小数写得更多。精确的含义是误差来源可解释、窗口可重复、样本足以比较，并且同时报告中位数和尾部；若噪声超过收益，应先改善实验而不是放大结论。
25.5 反复调整
25.5 反复调整要像小步实验：一次选择一个候选，记录结果和回退理由，下一轮从干净基线开始。累积多个未验证改动后只看总耗时，会丢失因果链，也无法知道哪一项真正带来收益。
25.6 代码调整方法总结
25.6 代码调整方法总结可以压缩为四句：先定目标，后测基线；先找热点，再改一点；报告分布，拒绝偶然；收益不足或代价过高，就回到清晰的原实现。
推荐读物
推荐读物应帮助读者理解测量、算法复杂度、硬件行为和可维护性之间的边界。阅读资料可以产生候选假设，却不能替代本项目的基线、热点证据和回归检查。
算法和数据类型
算法和数据类型常常比局部表达式更能改变性能上限。选择数据结构时同时估计复杂度、访问局部性、空间占用和错误语义；如果改变类型会损失精度或溢出，就先把这些边界写进合同。
关键点
关键点是：性能调整必须可测、可解释、可回退。若候选只在一个样本上更快，或需要牺牲正确性、可读性、可移植性才能成立，就应保留基线并拒绝该候选，而不是把数字包装成结论。
最小可重放实现
contract = { input, version, environment, window, limits }
baseline = measure(reference, contract, repeats=30)
hotspot = locate(baseline, real_load=true)
candidate = change_one_mechanism(reference, hotspot)
result = compare_alternating(reference, candidate, contract, repeats=30)
assert result.correctness == baseline.correctness
assert replay_after_reset(candidate, contract) == result.trace这段草图表达的是独立教学合同，不复制原书代码。实际记录至少包含 p50、p95、错误率、峰值资源、编译参数、首个偏离、接受或拒绝理由，以及重置后同一输入的重放结果。
故障诊断与误区
本页小结
- 先把“更快”写成指标、负载和可接受边界。
- 基线必须可重复，热点必须来自真实负载。
- 候选一次只改一个机制，并保持正确性合同。
- 复测看分布、尾部和质量代价，不追逐最好值。
- 重置后能重放同一轨迹，才有资格接受调整。
练习
问题 1：建立一份基线记录 你要比较两种 JSON 解析实现。请列出至少五个必须固定或记录的条件，并说明为什么不能只记录一次最快耗时。
问题 2：改 Demo 代码并判断候选 在专属实验中把场景切到“边界负载”，再把候选改成“只报告平均值”。请补写一段代码或伪代码，使它同时保留正常值、恰好边界、越界一步和重置重放的结果，并给出接受条件。
问题 3：做一次质量权衡 一个候选让平均延迟下降 8%，却让 p95 上升 12%，并多占 10% 内存。请依据本章的性能目标、统计复测和质量权衡写出决定流程。
名词解释
本章出现的专业名词，用大白话再讲一遍。
- 性能目标
在一组明确输入下，说明多快算合格、资源最多能用多少、哪些回归不能接受的验收条件。
- 基线测量
在改代码以前，按固定条件多次测量原实现，留下以后可以对照的参考分布。
- 热点定位
从真实负载的记录中找出最值得先验证的耗时或资源集中处，而不是凭代码外观猜测。
- 候选调整
只改变一个机制的可回退改动，用来检验它是否真的带来收益并保持正确性。
- 统计复测
交替运行基线和候选，比较中位数、尾部、波动和回归，而不是只看最好一次。
- 质量权衡
把速度、正确性、资源、可读性和可移植性放在一起，按明确优先级决定是否接受。
资料与边界
本章目录范围以公开中文试读目录核对，并参考Microsoft Press 的 Code Complete 书页确认英文版书目信息；性能测量与质量边界再对照 IEEE SWEBOK v4.0a 和 C++ Core Guidelines。本文的实验、伪代码、机制图和练习均为独立重写，不复制原书正文。