数值、单位与位

从 120ms 降到 90ms，减少了百分之几？

使用工具

改善报告可能同时出现“快了 25%”“快了 33%”或“变成原来的 75%”。同一组测量值因分母或指标不同，可得到不同结果。先明确基准与描述对象，比立即找计算错误更有效。

用比例工具比较示例处理时间 120ms 与 90ms。它根据输入计算，不测量实际服务。即便两值测量条件不同也能算出结果，因此计算成功不是比较公平的证明。

在增减率模式输入原值 120、新值 90，结果 -25%，公式为 (90－120)÷120×100。负号表示耗时减少，可以说“处理时间缩短 25%”，不代表性能变差。

比较条件

before = 120 ms
after = 90 ms
difference = -30 ms
change = -25%

输入前先统一单位。若把 120ms 与 0.09 秒直接输入为 120 和 0.09，工具无法知道单位不同。比例虽无量纲，原始两值仍需同一尺度；毫秒与秒、byte 与 KB 应先换算。

比例模式输入部分 90、基准 120，得到 75%，表示新耗时占原耗时的比例。剩余 75%，减少的是 25%。如果报告标题是“减少率”，不能把 75% 直接贴上去。

如果从 120ms 真正减少 75%，剩下应为 30ms，而不是 90ms。简短标签也要区分“原来的 75%”“减少 25%”“减少 75%”。公式正确，不代表措辞不会误导。

交换为原值 90、新值 120，增幅约 33.3333%。差仍是 30ms，分母却变为 90。增减率不对称，交换顺序不只是改变符号，应同时检查公式与结果。

同样，100 增加 20% 为 120，再减少 20% 得到 96，不会回到 100，因为第二次基准更大。合并折扣或容量变化时，不要直接加减百分比，应按实际顺序计算各阶段。

假设逐件串行且没有其他等待，120ms 一件约为每秒 8.333 件，90ms 约为 11.111 件，吞吐量增加约 33.333%。这与耗时减少 25% 不矛盾，因为比较的是倒数量。

实际服务有并发、排队、外部调用和其他限制，简单倒数模型不能保证服务器容量增加 33%。应区分实测“单件耗时减少 25%”与有条件的“同条件串行吞吐量约增加 33%”。

比例之间的直接差用百分点表达：2% 到 1% 是下降 1 个百分点；相对原来的 2%，则减少 50%。增减率模式输入 2 和 1 得到 -50%。仅说“下降 1%”容易产生歧义。

还要看原始次数：100 次中 2 次与 1 次，十万次中 2000 次与 1000 次，比例变化相同，但证据量不同。工具不判断统计显著性或因果，不能仅凭比例就断言是改善效果而非随机波动。

原值为 0 时会除以零，工具拒绝给出普通增减率。0 到 1 不能写成增加 100%，更适合写“从 0 件增至 1 件”或“新增 1 件”，明确数量和状态。

很小的非零基准也会产生大比例：1 到 10 增加 900%，实际只多 9 件。只突出百分比会隐藏规模。小基数或负基准尤其需要确认通常公式是否表达所需含义，并附绝对差。

可写“平均耗时从 120ms 降为 90ms，减少 30ms，相对原值减少 25%”。平均值应与平均值、中位数与中位数比较，并统一测量条件。拿优化后最快一次对比原平均或最坏值，算对了也不证明改善。

工具负责核对输入值的算式。基准选择、何谓改善、证据强度属于其他判断。写结论前，比较反向变化、剩余比例和绝对差，可避免百分比脱离上下文。

上午 100 次中错误 10 次，为 10%；下午 900 次中错误 9 次，为 1%。直接平均得 5.5%，但全天是 1000 次中 19 次，即 1.9%。时段请求数不同，不能等权平均。先合计原次数，再输入部分 19、基准 1000；只收集百分比会丢掉合并所需的分母。

前后比较也要统一范围。所有请求的错误率与单一功能的错误率不是同一对象，应先核对时间段、功能范围和失败定义。数字能输入不代表比较有意义。若汇总条件改变，应连同数值一起记录，避免把定义变化误当改善。