Hone 如何评估性能优化

许多 PC 调整都试图让自己听起来很有说服力：修改一个注册表项、禁用一项 Windows 功能、调整一个设置，然后立刻把它称为 FPS 提升。

对 Hone 来说，这还不够。

在添加一项优化之前，我们需要了解它改变了什么、为什么可能有效，以及如何对它进行测试。如果无法回答这些问题，我们就不会发布它。

简要说明

每项 Hone 优化都必须具备：

• 一个需要解决的真实问题
• 对其改动内容的清楚解释
• 一个可衡量的目标
• 已知风险
• 安全撤销的方法
• 足以证明改动合理的证据
• 对可能受益系统的明确界定

一项调整不必帮助每一台 PC，但它必须有合理依据，并且不能制造比原问题更严重的新问题。

在较小的屏幕上，将焦点移到图中，然后使用方向键或横向滑动浏览。

1. 从问题出发

我们首先关注玩家可能遇到的常见问题，例如：

• 后台活动引起的卡顿
• 不稳定的帧时间
• 较高的输入延迟
• 磁盘活动引起的短暂停顿
• 连接负载较高时的网络延迟
• 与游戏争夺 CPU 或内存的应用程序

如果无法描述问题，这项调整就会被直接否决。

“这个设置存在”不是更改它的理由。“这个设置控制的行为可能在游戏过程中引起延迟”才是值得研究的方向。

2. 了解调整改变了什么

每项优化都需要直接、清楚的解释。

我们应该能够回答：

• 它会影响 Windows 的哪个部分？
• 应用后，什么行为会发生变化？
• 这种变化为什么可能影响游戏？
• 哪些系统最有可能受益？

以我们的设备亲和性调整为例，它会改变某些硬件任务在 CPU 核心之间的分配方式。在部分系统上，移动这些任务可以减少资源争用和延迟。

这并不能证明该调整总是有效，但它为我们提供了一个可以测试的作用机制。

如果无法解释作用机制，我们就会把这项调整视为猜测。

3. 找出风险

在寻找性能收益之前，我们先寻找可能出现的问题。

根据改动内容，一项优化可能影响：

• 稳定性
• 帧显示的平稳程度
• 输入延迟
• 驱动程序和已连接设备
• 游戏启动
• 反作弊兼容性
• 功耗和温度
• Windows 更新

有些改动比其他改动更容易控制。减少游戏期间的后台活动，比改变设备的底层行为更容易撤销。

风险较高的调整不会被自动否决，但它需要更有力的证据、更精确的适用范围和可靠的回滚方式。

如果无法安全撤销一项改动，我们就不会轻率地对待它。

4. 定义什么是成功

并非每项优化都以提高平均 FPS 为目标。

一项调整也可能用于减少卡顿、改善帧显示的平稳程度、降低输入延迟、减少后台活动或稳定网络性能。

我们根据具体主张选择测试方法：

• FPS 与流畅度： 平均 FPS、1% 低帧和 0.1% 低帧、帧时间以及卡顿
• 延迟： 实测 PC 延迟、驱动程序时序、中断行为或 CPU 调度
• 存储： 读写延迟、响应时间和资源加载时的短暂停顿
• 网络： Ping、抖动、数据包行为和缓冲膨胀

这很重要，因为错误的衡量方式可能让一个薄弱的结果看起来像成功。

网络改动不应由 FPS 来判断。不能因为平均 FPS 没有变化，就否定延迟方面的改善。如果卡顿变得更严重，平均 FPS 更高也不能算作成功。

在较小的屏幕上，将焦点移到图中，然后使用方向键或横向滑动浏览。

5. 进行受控测试

PC 性能存在波动。

着色器编译、Windows 任务、温度、后台应用程序、不同地图、服务器状况，甚至测试时玩家注视的方向，都可能改变结果。

我们会尽可能控制这些因素：

• 使用同一台 PC 和相同硬件
• 使用同一款游戏、地图、场景、路线或回放
• 使用相同的画面设置
• 使用相同版本的 Windows 和驱动程序
• 使用相同的电源计划
• 运行相同的后台应用程序
• 使用相同的采集方法和测试时长
• 使用相同的 FPS 上限和同步设置
• 使用相同的重启条件

我们每次也只测试一项改动。如果同时启用五项调整，就无法判断哪一项带来了帮助或引起了问题。

一次表现良好的测试还不够。

对于每台 PC，我们会在应用调整前运行 3 至 5 次基准测试。然后只应用一次调整，必要时重启，再运行 3 至 5 次相同测试。

因此，每次前后对比在每台 PC 上总共包含 6 至 10 次测试。重复测试有助于我们考虑正常波动，并识别受到着色器编译、缓存或其他临时条件影响的结果。

比较结果之前，我们先查看各次基准测试之间的波动幅度。只有当应用后的结果超过正常的基准波动，而且变化在多次测试中持续出现时，这项调整才会被视为改善。

如果调整前后的结果过于接近，结论就是“没有可衡量的差异”。

在我们得出结论之前，每项调整都会经过同一流程。如果一个结果无法经受重复测试，我们就不会称其为改善。这正是 Hone 与大多数优化工具的区别所在。

在较小的屏幕上，将焦点移到图中，然后使用方向键或横向滑动浏览。

6. 将结果与风险进行比较

可衡量的改善并不一定值得发布。

低风险改动带来的微小但可重复收益可能很有价值。同样的收益却未必足以证明一项可能引起崩溃、卡顿或设备问题的改动是合理的。

我们会审查完整结果：

• 改善幅度有多大？
• 结果是否可以重复？
• 帧时间稳定性是否得到改善？
• 延迟是否得到改善？
• 是否有其他指标变差？
• 系统是否保持稳定？
• 改动能否撤销？
• 它是否只对特定硬件或游戏有效？

问题不只是某个数字是否上升。收益必须足以证明改动合理。

7. 明确它在何处有效、何处无效

大多数优化都有适用条件。

一项调整可能在以下情况中有效：

• 游戏受 CPU 性能限制
• 后台应用程序与游戏争夺资源
• 系统存在驱动程序延迟峰值
• 存储活动引起短暂停顿
• CPU 较旧或可用资源较少
• 连接繁忙时网络延迟上升

这并不表示该调整本身薄弱。

我们宁愿提出能够得到证据支持的具体结论，也不愿向所有人承诺 FPS 提升。

8. 保留、修改或否决

每项优化最终都会得到以下三种决定之一。

保留

符合以下条件时，我们会保留它：

• 作用机制清楚
• 目标指标得到改善
• 结果可以重复
• 风险合理
• 改动可以撤销
• 我们知道它应当在何处使用

“可接受的风险”并不表示没有风险，而是指可能的不利影响有限、已经了解并且可以恢复。

修改

有时构想本身合理，但实现方式还没有准备好。

调整可能改善一个指标，却让另一个指标变差。它可能需要仅针对特定硬件或游戏，也可能需要更合适的设置或更安全的回滚方式。

基准测试结果为正，并不表示我们会自动发布这项调整。

否决

出现以下情况时，我们会否决一项调整：

• 无法解释它改变了什么
• 结果无法重复
• 收益小到没有实际意义
• 它会引起不稳定或卡顿
• 兼容性风险过高
• 无法安全撤销
• 证据不支持相关主张

否决一项调整始终是流程的一部分；发布未经证实的调整才是失败。

示例：设备亲和性

我们按照本文介绍的方法测试了这项优化。测试采用相同的配置、场景和设置，在应用调整前采集五次数据，应用后再采集五次。结果显示，平均性能从大约 177 FPS 小幅提升到 182 FPS。平均帧时间和实测 PC 延迟也略有改善。

我们没有过早宣称“这项调整可以提升 FPS”，而是得出了以下结论：

在这套系统上，该调整改善了平均 FPS 和实测 PC 延迟。在得出更广泛的结论之前，还需要进行更多测试。

在较小的屏幕上，将焦点移到图中，然后使用方向键或横向滑动浏览。

Hone 不会作出的主张

Hone 不会宣称每项优化都能改善每一台 PC。

一次基准测试无法证明一项调整能适用于不同游戏、硬件、驱动程序和 Windows 版本。我们也不会为了提高性能而修改游戏内存、反作弊文件或其他敏感游戏文件。性能不应依赖范围宽泛、只是听起来很专业的说法。

我们的目标不是建立最长的调整列表，而是有选择地采用那些我们能够解释、测试、精确应用并撤销的改动。

这就是我们希望每项 Hone 优化都能达到的标准。