Stopwatch测IO不准因受磁盘缓存等干扰；BenchmarkDotNet通过预热、多轮迭代、GC控制和统计剔除确保稳定态性能测量，需禁用GCTimer、手动清缓存并规范文件生命周期管理。
为什么直接用 Stopwatch 测 IO 性能会不准
文件操作受磁盘缓存、预读机制、系统调度影响极大，单次 Stopwatch 计时容易被缓存“骗过”——比如第二次读同一文件快得离谱，不代表真实冷路径性能。BenchmarkDotNet 通过自动预热、多轮迭代、GC 控制和统计剔除（如排除前 10% 最慢样本），才能反映稳定态下的相对开销。
- 默认启用
JitOptimizations = true，避免调试模式干扰 - 强制每次运行前清空 OS 文件缓存（需管理员权限 +
MemoryDiagnoser配合ClearFileCache） - 对异步方法（如
ReadAllTextAsync）自动识别并正确处理同步上下文
如何配置 BenchmarkDotNet 支持文件 IO 基准测试
关键不是加引用，而是绕过默认陷阱：必须禁用内存诊断的自动 GC 压力注入（它会干扰 IO 调度），并手动控制文件生命周期。推荐最小可行配置：
[MemoryDiagnoser(disableGcTimer: true)]
[ShortRunJob]
[ClrJob, CoreJob] // 同时测 .NET Framework 和 .NET Core 表现
public class FileIoBenchmarks
{
private string _testFilePath;
<pre class="brush:php;toolbar:false;">[GlobalSetup]
public void Setup()
{
_testFilePath = Path.GetTempFileName();
File.WriteAllBytes(_testFilePath, Enumerable.Repeat((byte)65, 1024 * 1024).ToArray()); // 1MB 测试文件
}
[GlobalCleanup]
public void Cleanup() => File.Delete(_testFilePath);}
-
disableGcTimer: true防止内存诊断器在每次迭代前强制 GC，否则 IO 等待会被 GC 暂停污染 -
ShortRunJob减少预热时间，适合 IO 这类耗时较长的操作 -
GlobalSetup/Cleanup确保每个 benchmark 方法用同一份干净文件，避免残留缓存干扰
对比 FileStream.Read vs File.ReadAllText 的典型陷阱
表面看 File.ReadAllText 更简洁，但基准结果常显示它比手动 FileStream + StreamReader 慢 15–30%，原因不在算法，而在默认行为差异：
-
File.ReadAllText默认用UTF8Encoding且encoderFallback开启，每次读都做 BOM 检测和编码验证 - 手动
FileStream可复用缓冲区、跳过编码检查（如已知是 ASCII）、控制bufferSize（默认 4KB 太小，IO 密集场景建议 64KB+） - 异步方法（
ReadAllTextAsync）在小文件上反而更慢——线程调度开销盖过了并发收益
实操建议：测纯吞吐优先用 FileStream.Read + 预分配 byte[]；测字符串处理逻辑才引入 StreamReader，并显式传入 new UTF8Encoding(encoderShouldEmitUTF8Identifier: false)。
如何让结果真正反映“冷盘读取”性能
BenchmarkDotNet 默认无法清除 Windows 系统级文件缓存（即 standby list），导致多次运行实际走内存。必须手动干预：
- 以管理员身份运行 benchmark 程序
- 在
GlobalSetup后插入：ClearFileCache();（调用SetSystemFileCacheSize+EmptyWorkingSet） - 或改用
FileOptions.NoBuffering | FileOptions.WriteThrough打开文件（仅限固定大小、对齐读写） - 验证是否生效：观察每次运行的
Mean时间是否稳定，而非逐轮递减
真正难的不是跑出数字，而是确认那串毫秒值背后没有被任何一层缓存悄悄优化掉——尤其当对比 SSD 和 HDD 时，这个步骤漏掉，结论就全偏了。
