在 Windows 上正确比较不同版本程序运行速度的方法

想在 Windows 上比较程序的版本 A 与 B。 这时最不该做的，就是在同一台机器上各跑一次，然后说“看起来 B 快 8%”。

这 8% 也许真的来自代码差异。 但实际情况往往是，它其实来自 Power mode（电源模式）、Power plan（电源计划）、散热、后台更新、搜索索引、病毒扫描、亲和性、执行顺序、缓存状态 当中的某一项——这在 Windows 基准测试中是很常见的事。接下来要做的，是把这些条件一个一个排除掉的枯燥工作。

flowchart TB
    accTitle: “看起来快 8%”的真实来源
    accDescr: 各跑一次得到的差异也许来自代码，但更常见的是来自电源、散热、后台或缓存中的某一项，需要把条件一个一个排除掉的示意图。
    one1["各跑一次进行比较"] --> dif2["得出“看起来快 8%”"]
    dif2 -->|"也许是"| code1["真的来自代码差异"]
    dif2 -->|"常见的真实来源"| env1["电源、散热、噪声、缓存"]
    env1 --> crush1["把条件一个一个排除掉"]

图1：只跑一次得到的差异未必来自代码，不把条件排除干净就无法断言。

本文整理在 Windows 上比较不同版本程序运行速度时，如何 尽可能贴近代码本身的差异 来做比较。 主要面向 Windows 11，但 powercfg、start 之类的命令大多在 Windows 10 上同样适用。

先要掌握的术语

正文里有一些术语会以英文原样出现。为了避免第一次读到时卡住，先在这里汇总。

先说结论

提高可复现性的要点，归纳起来就是以下 6 条。

1. 先决定“想比较什么” 想看的是代码差异，还是真实用户的体感，需要对齐的环境是不一样的。

2. 把 Power mode（电源模式）与 Power plan（电源计划）当成两件事分别记录 在 Windows 上如果这里处理得马虎，比较很容易变成在比较 OS 的省电策略。

3. 把冷机状态下的第一次与热机之后的稳定状态分开 只有第一次快、或者只有后半段慢，都不是罕见现象。

4. 按 A→B→A→B 的方式交替执行 先把 A 全部跑完再跑 B，就会把散热与后台状态的偏差全吃进去。

5. 不只看平均值，还要看中位数与离散程度 只要有一个离群值，整体图景就会被大幅扭曲。平均值比想象中脆弱。

6. 差异较小时，用 ETW / WPR 深挖到原因为止 只凭体感争论，双方的主张都没有依据，只会各说各话。

图中实线表示始终成立的关系，虚线表示带条件的关系（成立条件写在详情页各关系的说明中）。关系的完整列表（共 25 条，附依据与确信度）以及主要概念的定义，汇总在知识地图详情页（日文）。数据：JSON-LD / Turtle

先决定你到底要比较什么

“速度比较”听起来只是一件事，其实分成两种。

1. 想看代码差异的比较

因为算法变更、数据结构变更、编译器优化、运行时更新等原因，想知道 实现本身是否变快 的比较。

这种情况下要尽量削减环境噪声。 使用基准测试专用的会话、固定 Power mode（电源模式）、关闭通知、抑制搜索索引与同步，必要时甚至做 clean boot。

2. 想看真实用户体感的比较

想知道发布之后，用户在日常的 Windows 环境中体感到的速度。

这种情况下 不能把现实中存在的噪声全部消除。 在包含 OneDrive 同步、Defender、通知、普通电源配置在内的“接近日常”的环境下比较，结果才会更贴近现实。

把这两者混在一起，结论就会拧巴。 “在实验室里快 12%，在现实中却只是误差”“现实中更快，但 CPU 时间没变”这类情况很常见。

flowchart TB
    accTitle: 不要把两种比较混在一起
    accDescr: 想看代码差异的比较要尽量削减环境噪声，想看真实用户体感的比较要保留现实噪声、在日常环境下测量，两者混在一起会让结论拧巴的示意图。
    q5["想比较什么"] -->|"代码差异"| lab1["削减噪声的实验室环境"]
    q5 -->|"真实用户体感"| real1["保留噪声的日常环境"]
    q5 -.->|"混在一起"| twist2["结论会拧巴"]

图2：目的不同，该对齐的环境正好相反，所以要先决定做的是哪一种比较。

Windows 上导致结果波动的主要因素

先把会让结果晃动的因素粗略列一遍。

一句话，即使是“同一台 Windows 机器”，只要条件没有对齐，就是另一次实验。

flowchart TB
    accTitle: 条件不对齐就是另一次实验
    accDescr: 即使在同一台 Windows 机器上测量，只要从硬件到电源、散热、后台、构建条件这些多层条件没有对齐，实质上就是另一次实验，只有固定并记录条件才算得上比较的示意图。
    same1["在同一台 Windows 机器上测量"] -.->|"条件没有对齐"| oth1["实质上是另一次实验"]
    same1 -->|"固定并记录多层条件"| cmp1["这才算得上比较"]

图3：即使机器相同，只要跨层的条件没有对齐，比较就不成立。

Power mode（电源模式）与 Power plan（电源计划）要分开考虑

这一点相当重要。

Windows 里既有设置应用中的 Power mode（电源模式），也有传统意义上的 Power plan（电源计划）（用 powercfg 能看到的电源计划）。 两者外观相似，容易被混为一谈，但处理得马虎会让比较条件变得含糊，结果也就失去了可复现性。

在 Windows 的设置应用中，可以从 Settings > System > Power & battery 选择 Power mode。 Microsoft 的文档中提到，Plugged in / On Battery 各自可以在 Best power efficiency、Balanced、Best performance 之间切换。而且 Power mode 一旦改变，背后的电源相关配置与 PPM（Processor Power Management）的行为也会随之改变。也就是说，仅仅这里不同，核心停放与性能调度的策略就可能不同。

另一方面，Power plan 是 Balanced、High performance 这类传统的电源计划。 可以用 powercfg /list 或 powercfg /getactivescheme 确认。

麻烦的地方在于，Windows 同时存在 Power mode（电源模式）这一层覆盖（overlay） 和 Power plan（电源计划）。 把两者的关系画成图，就是下面这样。

flowchart TB
    subgraph upper["上层：Power mode - 覆盖层"]
        direction LR
        M1["Best power efficiency"]
        M2["Balanced"]
        M3["Best performance"]
    end

    subgraph lower["下层：Power plan - 电源计划"]
        direction LR
        P1["Balanced"]
        P2["High performance"]
        P3["custom plan"]
    end

    UI["设置应用<br/>Power and battery 中的 Power mode"] --> upper
    CLI["用 powercfg /setactive 切换"] --> lower
    upper --> PPM["实际生效的电源配置<br/>PPM 与图形的子组"]
    lower --> PPM
    AC["接 AC 供电还是电池"] --> PPM
    PPM --> RESULT["频率上限 / 核心停放 / 性能调度"]

图4：Power mode（覆盖层）与 Power plan 这两层再加上 AC/DC，共同决定了实际生效的电源配置。

只看上层或只看下层，都决定不了实际行为。所以基准测试结果至少要记录下面这些内容。

• 接的是 AC 还是电池
• Power mode 是什么
• Active power plan 是什么

没有写下这 3 项的基准测试结果，事后回看时无法还原当时的条件。

flowchart TB
    accTitle: 至少要记录的 3 项
    accDescr: 接的是 AC 还是电池、Power mode 是什么、Active power plan 是什么这 3 项，如果不随结果一起记录下来，事后回看时就无法还原条件的示意图。
    r1["接的是 AC 还是电池"] --> rec2["与结果一起记录下来"]
    r2["Power mode"] --> rec2
    r3["Active power plan"] --> rec2
    rec2 --> rst1["事后可以还原条件"]

图5：电源相关的这 3 项是最低限度的记录，不写下来结果就整个无法复现。

首先应该固定的电源条件

1. 笔记本电脑务必接 AC 电源再比较 靠电池运行时容易被加上意料之外的限制。

2. 固定 Power mode 如果是做基准测试，可以先试 Best performance。

3. 记录 Active power plan 用 powercfg 把当前值保留下来。

powercfg /list
powercfg /getactivescheme

powercfg /list 的输出，在 Microsoft 的文档中是以下面这种形式给出的。处于活动状态的计划所在行的行尾会带上 *。在日语环境下，标题和计划名称会以日语显示。

Existing Power Schemes (* Active)
-----------------------------------
Power Scheme GUID: {guidPlan1}  (Balanced) *
Power Scheme GUID: {guidPlan2}  (Power saver)

把这里输出的 GUID 原样抄到结果文件的 power_plan 字段。要点是记录 GUID 而不是名称，因为同样叫“平衡”的，也可能是复制或自定义出来的另一个计划。

1. 必要时切换到 High performance

# Balanced
powercfg /setactive 381b4222-f694-41f0-9685-ff5bb260df2e

# High performance
powercfg /setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c

Power mode 能用命令切换吗

这里是容易卡住的地方。在 powercfg 已公开的命令行选项列表中，没有可以重新选择 Power mode（覆盖层）本身的选项。正规的做法是从设置应用的 Settings > System > Power & battery 里切换。

另一方面，powercfg 支持对覆盖方案的 配置值进行读写。文档中有下面这些说明。

• 给 powercfg /q 传入覆盖层的别名和子组，就可以读取覆盖层一侧的配置
• powercfg /setacvalueindex 和 /setdcvalueindex 也可以用于覆盖方案
• 如果没有指定方案，操作对象就是 当前处于活动状态的覆盖层（没有覆盖层时则是当前的电源计划）
• 别名的清单可以用 powercfg /aliases 查看

也就是说，用命令能做的是“读取并调整当前生效的覆盖层的内容”，而不是改变“选择哪一个覆盖层”。作为基准测试的复现步骤，现实的做法是 在设置应用里人工固定 Power mode，并把这个值写进结果里。操作手册中要写明“已把 Power mode 设置为 Best performance”，并在每次执行前在界面上确认一遍。

flowchart TB
    accTitle: powercfg 能做什么、不能做什么
    accDescr: powercfg 支持读写当前生效的覆盖层的配置值，但没有可以改变选择哪一个覆盖层的选项，因此现实的做法是在设置应用里人工固定 Power mode 并把值记录下来的示意图。
    pc1["powercfg"] -->|"能做到"| rw1["读取并调整覆盖层的内容"]
    pc1 -.->|"做不到"| sel1["改变选择哪一个覆盖层"]
    sel1 --> hand1["在设置应用里人工固定并记录"]

图6：覆盖层的选择无法用命令改变，只能人工固定并记录下来。

“找不到 High performance”是很常见的情况

这里也是一个坑。 Microsoft 的文档说明，在支持 Modern Standby 的设备上，只允许使用 Balanced 或由 Balanced 派生出来的计划。 所以与其想“找不到 High performance，是不是坏了？”，更可能是 这台机型在设计上本来就是这样。

另外，Microsoft 还提示：“如果 Power mode 无法更改，可能是选中了 custom power plan，可以先试着选 Balanced。”当 Power mode 的界面动不了时，先怀疑这一点会更快。

flowchart TB
    accTitle: 找不到 High performance 时怎么看
    accDescr: 支持 Modern Standby 的设备只允许 Balanced 或其派生计划，所以看不到 High performance 属于设计使然；当 Power mode 的界面无法更改时，要先怀疑是否选中了 custom plan 的示意图。
    nohp1["找不到 High performance"] --> ms1["支持 Modern Standby 就是设计如此"]
    nomv1["Power mode 的界面动不了"] --> cst1["怀疑选中了 custom plan"]
    cst1 --> bl1["先试着选 Balanced"]

图7：计划不出现、界面动不了未必是故障，先看机型的设计和当前选中的计划。

压制后台噪声

即使我们想安静地测量，Windows 也会在后台跑更新、建索引、做扫描。首先要把这些活动的量降下来。

先重启，然后等它安静下来

修改配置之后先重启一次，登录后不要马上开跑，等上几分钟。 刚启动时，更新、索引、同步、Defender 以及各种常驻程序都还很活跃。

flowchart TB
    accTitle: 重启后等它安静下来
    accDescr: 修改配置后先重启一次，由于刚启动时更新、索引、同步、Defender 等还在运行，所以登录后不要马上开跑，等几分钟再开始测量的步骤示意图。
    chg1["修改配置"] --> rb1["重启一次"]
    rb1 --> wt1["登录后等几分钟"]
    wt1 --> ms2["然后再开始测量"]
    rb1 -.-> nzz1["刚启动时常驻程序还很活跃"]

图8：要等重启后后台活动安静下来，再开始测量。

严格的比较就用 clean boot

Microsoft 提供了通过 clean boot 把启动配置降到最小的操作步骤。 做法是用 msconfig 停用 Microsoft 以外的服务，再用 Task Manager 停用 Startup apps。

这种方式在 降噪 上相当有效。 不过它离日常使用环境比较远，更适合用在“为了观察代码差异而做的实验室式比较”中。

让通知安静下来

Windows 的通知横幅看起来无关紧要，实际上相当碍事。 它不只是视觉上的干扰，还可能改变执行时机、焦点以及后台应用的活动。

手动开启 Do not disturb，或者至少在基准测试期间关闭通知。

抑制搜索索引与同步

如果基准测试对象属于会读取大量文件、写出大量生成物、反复重建源码树的类型，搜索索引与云同步就会在不显眼处产生影响。

• 把基准测试用的目录排除在搜索范围之外
• 停止 OneDrive / Dropbox / Google Drive 之类的同步
• 关闭浏览器、Teams、Discord、Slack

这些操作看起来不起眼，但起作用的时候相当明显。

flowchart TB
    accTitle: 会影响文件操作密集型基准测试的噪声
    accDescr: 对于会大量读写文件的基准测试，搜索索引、云同步和常驻应用都会影响测量结果，因此要通过排除设置或停止这些程序来减少噪声的示意图。
    ix1["搜索索引"] --> hit1["影响文件操作密集的基准测试"]
    sy1["云同步"] --> hit1
    ap2["常驻应用"] --> hit1
    hit1 --> cutn1["用排除与停止来减少噪声"]

图9：读写文件越多的基准测试，停掉索引与同步的效果越明显。

不对齐散热条件的比较，基本上是在比较散热

CPU 和 GPU 在冷机状态与热机之后，运行频率是不同的。也就是说，即使是同一份代码，每次执行的条件都在变。 笔记本电脑、超薄迷你主机、小型台式机尤其明显。

flowchart TB
    accTitle: 散热改变条件的机制
    accDescr: CPU 和 GPU 在冷机状态与热机之后运行频率不同，因此即使是同一份代码，每次执行的条件都会变化，不对齐散热条件的比较基本上就是在比较散热的机制示意图。
    cold1["在冷机状态下执行"] --> hot1["热起来后频率会变"]
    hot1 --> vary1["每次执行条件都在变"]
    vary1 -.-> heatc1["不对齐就是在比较散热"]

图10：频率会随温度变化，不对齐散热条件就变成在比较散热而不是代码。

需要遵守的规则

• 尽量对齐室温
• 固定笔记本电脑的摆放方式
• 固定 AC 适配器、扩展坞、外接显示器的配置
• 基准测试之前不要做重负载的工作
• 把首次执行与稳定状态分开测量

执行顺序要交替

避免先把 A 跑 10 次，再把 B 跑 10 次。 因为散热、缓存、后台活动的偏差会压在一边。

推荐下面几种做法中的任意一种。

• A B A B A B ...
• A B B A A B B A ...
• 事先生成随机顺序，再按该顺序执行

flowchart TB
    accTitle: 执行顺序决定偏差落在哪里
    accDescr: 先把 A 全部跑完再跑 B，会让散热、缓存和后台活动的偏差只压在其中一方身上，而交替或随机顺序执行可以把偏差分散到两边的示意图。
    seq1["先跑完全部 A → 再跑全部 B"] --> bias1["偏差只压在一边"]
    alt1["A B A B 交替或随机顺序"] --> even1["偏差分散到两边"]
    even1 --> fair1["可以把顺序的影响从差异中剔除"]

图11：把顺序集中起来就会连偏差一起比较，所以要交替或随机执行。

测量什么，决定了“快”的含义

把“快”压缩成一个数字，多半会出事。 在 Windows 上值得关注的代表性指标有下面 3 个。

1. Wall-clock time（实际耗时）

用户等待的时间。 它最贴近端到端的体感，所以要最先看这个值。

在 Windows 上，QueryPerformanceCounter（QPC）可用于获取高分辨率的时间戳。 如果是 managed code，基本上使用 Stopwatch 系列。 用 DateTime.Now 去看毫秒，未免有些不设防。

2. CPU time（用户态 + 内核态时间）

用 GetProcessTimes 可以获取的、进程实际使用 CPU 的时间。

它便于 观察计算效率。 例如 wall-clock 变快了但 CPU time 没变，那就可能是缓存、I/O、等待时间或调度在起作用。

3. Cycle count（CPU 周期数）

用 QueryProcessCycleTime 可以获取整个进程的 CPU 周期数。

它同样是衡量 CPU work 的指标，但展示的侧面与 wall-clock 不同。 特别是想确认“等待时间没变，但计算部分是否变轻了”的时候很有用。

flowchart TB
    accTitle: 3 个指标各自观察的侧面
    accDescr: wall-clock time 是用户等待的时间，CPU time 是进程实际使用 CPU 的时间，cycle count 是 CPU 周期数，三者展示不同侧面，组合起来才能读懂“快”的内容的示意图。
    spd1["读懂“快”的内容"] --> w1["wall-clock：等待的时间"]
    spd1 --> u1["CPU time：使用的 CPU 时间"]
    spd1 --> cy1["cycle：计算部分的轻重"]
    w1 -.-> mixr1["用组合来推测原因"]

图12：不要压缩成一个数字，要用 3 个指标的组合去读懂“快”的含义。

priority、affinity、NUMA 是最后的手段

这些手段有时确实有效。 但正因为有效，一开始就去动它们，容易制造出另一种现象。

先按常规方式测量

如果默认状态下就出现差异，这个差异本身就有价值。 一上来就加 /high 或 /affinity，就等于引入了 “真实 Windows 环境中不会出现的条件”。

flowchart TB
    accTitle: priority 与 affinity 是最后的手段
    accDescr: 先在默认状态下测量，出现差异时这个差异本身就有价值；一上来就固定优先级或亲和性，等于引入真实 Windows 环境中不会出现的条件，所以要在明确目的之后作为最后手段使用的示意图。
    def1["先在默认状态下测量"] --> val1["出现差异则差异本身有价值"]
    early1["一上来就用 /high 或 /affinity"] -.-> art1["引入现实中不会出现的条件"]
    val1 -->|"确有需要时，先定好目的"| lastr1["作为最后手段进行固定"]

图13：优先级与亲和性要在完成默认状态下的测量之后，带着目的去使用。

要用的话，先明确目的

• /high：不想被其他进程干扰
• /affinity：固定 CPU 分配后再比较
• NUMA 控制：在大型机器上把内存局部性也一并对齐

Windows 的 start 命令可以在启动时附加 priority class 和 affinity mask。

start "" /high /wait myapp.exe --bench case1.json
start "" /affinity F /high /wait myapp.exe --bench case1.json

但 /realtime 不要用

/realtime 虽然可以用，但 最好不要用。 它往往不是在降噪，而是在制造另一种问题。

推荐的测量步骤

把前面的内容整理成一套便于实际执行的步骤。

偏实验室的比较步骤

1. 固定比较对象
   • commit hash / build number
   • compiler / runtime version
   • Debug / Release
   • 有没有日志、assert、trace
2. 固定机器条件
   • Windows build
   • BIOS / UEFI version
   • driver version
   • 接 AC 电源
   • 室温、摆放方式
3. 固定电源条件
   • 决定 Power mode
   • 记录 Active power plan
4. 重启
5. 测试前等几分钟
6. 必要时做 clean boot
7. 加入 warm-up
8. A / B 交替执行
9. 保证执行次数
10. 保留中位数、最小值、最大值、p95
11. 保存 raw data
12. 差异较小时采集 ETW / WPR

要跑多少次

第 9 条“保证执行次数”也要定个大致标准。下面不是统计学上的严格解，而是实务中的折中方案。

所需时间可以按 单次执行时间 × 次数 × 版本数 + warm-up 来估算。如果单次处理需要 30 秒，A / B 各跑 30 次，加上 warm-up 大约是 35 分钟左右。当这个时间不现实时，与其削减次数，不如 把测量对象切小（只截取耗时较重的工序），这样思路更正。

如果不知道该在哪里收手，一个清晰的做法是 一边增加次数一边观察中位数的变化，等到再增加也不动了就停下来。

flowchart TB
    accTitle: 执行次数的收手点
    accDescr: 一边增加次数一边观察中位数的变化，等到再增加中位数也不再变动时就停下来，这是决定执行次数的实务做法的示意图。
    add2["增加次数继续跑"] --> mdz1["观察中位数的变化"]
    mdz1 -->|"还在变"| add2
    mdz1 -->|"增加也不再变"| stop1["就在这里停下"]

图14：次数不一定要事先定死，可以把中位数稳定下来的那个点当作收手点。

记录下来之后会派上用场的项目

基准测试的 CSV 或 JSON 里，至少保留下面这些内容会很有用。

timestamp,version,scenario,elapsed_ms,user_ms,kernel_ms,cycles,power_mode,power_plan,ac_or_dc,room_temp_c,notes

如果条件允许，再加上下面这些会更方便。

cpu_package_temp_start_c,cpu_package_temp_end_c,affinity_mask,priority_class,windows_build,driver_version

对基准测试来说，能不能在事后解释清楚 有时比 测量本身 更重要。

不只看平均值，也要看中位数与分布

平均值很方便，但在 Windows 基准测试中很容易被破坏。 只要有一次 Defender 介入、弹出一次通知、别的进程敲了一下 SSD，平均值就会被带偏。

flowchart TB
    accTitle: 平均值会被离群值带偏
    accDescr: 只要有一次 Defender 扫描、通知或其他进程的 I/O 混进来，平均值就会被带偏，因此要以中位数为主，结合 p95、p99 和 min/max 从分布上来看的示意图。
    once3["只混进一次噪声"] --> avg1["平均值被带偏"]
    med2["以中位数为主"] --> dist1["同时看 p95 / p99 与 min / max"]
    dist1 --> robust1["得到对离群值更稳健的读法"]

图15：平均值会被一次噪声破坏，所以要结合中位数与分布来读。

推荐下面这个组合。

• 中位数：先看这个
• p95 / p99：看尾部有没有恶化
• min / max：看离群的程度
• 箱线图或散点图：差异较小时很有用

出现差异时怎么读

结果的解读，组合起来看会更清楚。

只有 wall-clock 变快

可能是 I/O、等待时间、缓存或调度上的改善。

CPU time 和 cycle 都下降了

很可能是实现本身变轻了。

只有第一次慢 / 快

这是 cold / warm 的差异。要怀疑启动、初始化、缓存生成、JIT。

跑得越多越慢

要怀疑散热、降频、内存压力、后台活动。

flowchart TB
    accTitle: 从差异的形态读出原因
    accDescr: 只有 wall-clock 变快就看等待与 I/O，CPU time 和 cycle 都下降就是实现变轻，只有第一次不同就是 cold 与 warm 的差异，跑得越多越慢就怀疑散热与后台活动的读法示意图。
    pt2["观察差异是怎么出现的"] -->|"只有实际耗时"| c1a["等待、I/O 相关"]
    pt2 -->|"CPU 时间也减少"| c2a["实现变轻了"]
    pt2 -->|"只有第一次"| c3a["cold / warm"]
    pt2 -->|"后半段变慢"| c4a["散热、后台活动"]

图16：比起差异本身，差异出现的形态更能提示原因的方向。

用 ETW / WPR 挖到“为什么更快”

当差异较小、或者读不出原因时，转向 Windows 的 ETW（Event Tracing for Windows）系工具是正统做法。

Microsoft 的 Windows Performance Recorder（WPR）是基于 ETW 的记录工具，包含在 Windows ADK 中。 可以把 CPU、I/O、context switch、页错误等一次性采集下来。

最简单的用法大致如下。

wpr -start CPU -filemode

REM 在这里执行基准测试

wpr -stop trace.etl

用 WPA 打开之后，先看哪些图基本上是固定的。

做比较时，基本做法是 在同一场景下为 A 和 B 各采集一份跟踪，把同样的图并排来看。只看一份，是判断不出“这算慢吗”的。

走到这一步之后，就不再是 “B 快 3%”， 而是能说出 “B 的锁等待减少了，ready time 下降了” “A 的 file open 变多了，cold start 更慢” 这种带原因的结论。

flowchart TB
    accTitle: 从只有数字的差异走向带原因的差异
    accDescr: 当差异较小、读不出原因时，用 WPR 在同一场景下为 A 和 B 各采集一份跟踪，再用 WPA 把同样的图并排比较，就能从“快百分之几”变成带原因的结论的流程示意图。
    small2["差异较小、读不出原因"] --> tr1["用 WPR 采集 A 与 B 的跟踪"]
    tr1 --> cmp2["用 WPA 把同样的图并排来看"]
    cmp2 --> rsn1["能说出带原因的结论"]
    cmp2 -.-> onen1["只看一份判断不出是否算慢"]

图17：挖到 ETW 这一层，“快百分之几”就变成了“为什么更快”。

一页纸的检查清单

最后整理成可以直接贴进操作手册的形式。

固定

• 已固定比较对象（commit hash / build number / Debug 还是 Release / PGO 等构建条件 / 有没有日志和 assert）
• 笔记本电脑已接 AC 电源
• 已在设置应用里固定 Power mode
• 已用 powercfg /getactivescheme 确认 Active power plan
• 已关闭通知。已停止搜索索引与云同步
• 必要时已切换为 clean boot
• 已重启，并等了几分钟再开始

执行

• 已加入 warm-up
• 已把 cold（首次）与 warm（稳定）分开测量
• 已按交替或随机顺序执行 A / B
• 已定好次数再执行（参考上面的表）

记录

• 已保留每次执行一行的 raw data（elapsed_ms / user_ms / kernel_ms / cycles）
• 已保留接的是 AC 还是 DC、Power mode（电源模式）、Power plan（电源计划）的 GUID、Windows build、driver version
• 已保留室温与摆放状态
• 没有固定的条件也写下来了

解读

• 已看中位数，没有只凭平均值下判断
• 已用 p95 / p99 看尾部
• 已用 min / max 确认离群值
• 已用 wall-clock / CPU time / cycle 的组合推测原因
• 差异较小时已挖到 ETW / WPR

总结

在 Windows 上比较不同版本的程序时，真正管用的不是花哨的偏门技巧。 重要的是下面这些 朴素但能提升可复现性的做法。

• 固定并记录 AC / Power mode（电源模式）/ Power plan（电源计划）
• 把 cold 与 warm 分开
• A / B 交替执行
• 看中位数与分布
• 必要时做 clean boot
• 差异较小时用 ETW / WPR 挖到原因

而最重要的一点是，把固定了什么、没固定什么与结果一起写下来。 基准测试既是速度的比较，同时也是实验条件的记录。

没有写明条件的提速报告，别人无法确认能不能得到同样的结果。因为留下的只有数字，没有留下复现的办法。 反过来，只要条件写得扎实，即使差异很小，那个结果也是有价值的。

flowchart TB
    accTitle: 条件的记录决定结果的价值
    accDescr: 没有写明条件的提速报告只留下数字、没有留下复现的办法，而条件写清楚了即使差异很小也有价值，说明基准测试同时也是实验条件的记录的示意图。
    norec1["不写条件的报告"] --> onlyn1["只留下数字"]
    onlyn1 --> norep1["别人无法确认"]
    rec3["写了条件的报告"] --> rep1["留下了复现的办法"]
    rep1 --> worth1["即使差异很小也有价值"]

图18：基准测试的价值与其说在数字，不如说在于记录了固定什么、没固定什么。

参考资料

• Microsoft Support: Change the power mode for your Windows PC
• Microsoft Learn: Power Policy Settings
• Microsoft Learn: Customize the Windows performance power slider
• Microsoft Learn: Powercfg command-line options
• Microsoft Support: How to perform a clean boot in Windows
• Microsoft Support: Notifications and Do Not Disturb in Windows
• Microsoft Support: Search indexing in Windows
• Microsoft Learn: Configure custom exclusions for Microsoft Defender Antivirus
• Microsoft Support: Device Security in the Windows Security App
• Microsoft Learn: QueryPerformanceCounter function
• Microsoft Learn: Acquiring high-resolution time stamps
• Microsoft Learn: GetProcessTimes function
• Microsoft Learn: QueryProcessCycleTime function
• Microsoft Learn: start command
• Microsoft Learn: SetPriorityClass function
• Microsoft Learn: SetProcessAffinityMask function
• Microsoft Learn: Processor Groups
• Microsoft Learn: Windows Performance Recorder
• Microsoft Learn: WPR Command-Line Options
• Microsoft Learn: CPU Analysis in Windows Performance Analyzer - 在哪张图上看什么。
• Microsoft Learn: Set the Default Power Plan - powercfg -LIST 的输出示例。

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

在 Windows 上做基准测试时，结果波动的主要原因有哪些？

有很多层面的因素，包括 Power mode（电源模式）、Power plan（电源计划）、散热、后台更新、搜索索引、病毒扫描、优先级与亲和性、执行顺序、缓存状态等。即使是同一台 Windows 机器，只要这些条件没有对齐，实质上就是两次不同的实验。尤其是笔记本电脑，接 AC 电源还是靠电池运行会让行为出现很大差异，所以务必接 AC 电源进行比较，并把这些条件都记录下来。

Power mode（电源模式）和 Power plan（电源计划）有什么区别？

Power mode 是在设置应用的 Power & battery 中选择的 Best power efficiency、Balanced、Best performance 之间的切换，会影响背后的电源相关配置以及 PPM（Processor Power Management）的行为。Power plan 则是可以用 powercfg 查看的 Balanced、High performance 等传统电源计划。Windows 上这两者同时存在，所以基准测试结果至少要记录接的是 AC 还是电池、Power mode 是什么、当前的 Active power plan 是什么这三项。

找不到 High performance 电源计划，是设备故障吗？

很可能不是故障。Microsoft 的文档说明，在支持 Modern Standby 的设备上，只允许使用 Balanced 或由 Balanced 派生出来的计划。也就是说，这台机型在设计上就不会出现 High performance，这是很正常的情况。另外，如果 Power mode 的界面无法更改，可能是选中了 custom power plan，这时先试着切换到 Balanced 是比较快的排查方式。

比较版本 A 和 B 的速度时，应该按什么顺序执行？

应避免先把 A 全部跑完再跑 B，因为散热、缓存、后台活动的偏差会全部压在其中一方身上。建议按 A B A B 交替执行，或者按事先生成的随机顺序执行。同时还要把冷机状态下的第一次与热机之后的稳定状态分开测量，并且不只看平均值，还要看中位数、p95、最小值和最大值，这样才能避免结果被离群值带偏。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。