C# BenchmarkDotNet使用方法 C#如何进行代码性能基准测试

来源：这里教程网时间：2026-02-21 17:40:26 作者：

怎么用 BenchmarkDotNet 快速测一个方法的执行时间

直接加

[Benchmark]

特性，再用

BenchmarkSwitcher.Run<t>()</t>

启动就行。它会自动处理预热、多次迭代、统计异常值，比手写

Stopwatch

可靠得多。

常见错误是把待测逻辑写在构造函数或

Setup

里——这些不计入耗时。所有要测的代码必须严格放在带

[Benchmark]

的方法体内。

方法必须是
public
，不能带参数，返回类型为
void
避免在
[Benchmark]
方法里做 I/O、随机数生成、GC 调用等干扰项如果需要初始化数据，用
[GlobalSetup]
，但注意它只运行一次，不是每次迭代都调

如何对比两个算法（比如 List.Find vs for 循环）

把它们写成两个独立的

[Benchmark]

方法，放在同一个类里，

BenchmarkDotNet

会自动对齐运行环境、控制变量，并输出相对性能比（如 “MethodB is 3.2x faster than MethodA”）。

关键点在于：别手动“取平均”，也别只跑一次。BenchmarkDotNet 默认用

DefaultJob

，含 15 轮预热 + 30 轮主测量，每轮迭代数动态调整。你只需要保证两个方法操作等价的数据集（比如都查同一个

List<int></int>

）。

数据初始化建议放在
[GlobalSetup]
中，用
[Params]
控制不同规模（如
[Params(100, 1000)]
）若方法依赖外部状态（如缓存），需用
[IterationSetup]
确保每次迭代前重置避免在基准测试中使用
Console.WriteLine
或日志——I/O 会严重污染结果

为什么跑出来的 Mean 值波动大，甚至出现 NaN 或 “Overhead” 异常

这通常不是代码问题，而是 BenchmarkDotNet 检测到测量噪声超标，主动放弃该 benchmark。典型原因包括：方法太快（纳秒级）、JIT 编译未稳定、CPU 频率动态缩放、后台进程干扰。

给方法加点“工作量”：比如循环执行 100 次目标操作，再除以 100（注意别让编译器优化掉） 用
[SimpleJob(runsPerLaunch: 3)]
提高单次启动的稳定性在 Windows 上临时关闭“快速启动”，macOS 上禁用 Turbo Boost（
sudo pmset -a bcl 0
），Linux 上设 CPU governor 为
performance
如果仍报
Overhead
，检查是否误用了
async
方法——BenchmarkDotNet 不支持直接测
async
，得用
.GetAwaiter().GetResult()
同步等待（且确保不是 UI 线程）

发布模式下跑和 Debug 模式下结果差 10 倍正常吗

完全正常，而且你应该**只在 Release 模式下跑基准测试**。Debug 模式禁用 JIT 优化、插入调试桩、不内联方法，测出来毫无参考价值。

另外要注意：.NET 6+ 默认启用 ReadyToRun 和 Tiered Compilation，这些会影响首次运行耗时。BenchmarkDotNet 默认开启 tiered jitting，但如果你要模拟“冷启动”，得显式配置：

[SimpleJob(launchCount: 1, warmupCount: 0, targetCount: 1)]

，不过这种场景极少需要。

务必用
dotnet run -c Release
运行，而不是 Visual Studio 的“启动”按钮（它默认可能走 Debug）若引用了其他项目，确认其输出也是 Release 构建；NuGet 包优先选带有
Portable PDB
的 Release 版本 某些 LINQ 操作在 Release 下会被内联或折叠，Debug 下则保留完整调用栈——这也是性能差异的来源之一

真正难的是让两次测量环境一致：同一台机器、关掉杀毒软件、拔掉 USB 设备、避免 Chrome 后台刷新。哪怕只是多开一个 Electron 应用，都可能让 GC 时间抖动 20%。性能数字本身不重要，能复现的相对变化才值得信。