Stopwatch计时结果波动范围过大，求原因分析及解决建议

这种忽高忽低的计时结果我太熟悉了，本质上是系统级干扰和代码本身的小问题共同导致的，给你逐个拆解：

核心原因分析 #

• 操作系统上下文切换：你的程序线程不是独占CPU的，操作系统会随时把CPU时间片分给其他进程（比如后台杀毒、系统更新、甚至桌面弹窗）。一旦你的线程被暂停，那次循环的耗时就会瞬间拉爆，这就是你看到983微秒最大值的罪魁祸首。
• 垃圾回收（GC）的突然停顿：你在循环里不断往List<decimal>塞数据，List容量不足时会自动扩容，加上每次循环都新建Stopwatch对象，百万次下来必然触发GC。GC运行时会暂停所有托管线程，这时候计时自然会异常变长。
• Stopwatch重复实例化的额外开销：每次循环都新建Stopwatch，虽然这个开销很小，但积累下来也会给数据带来噪音，而且完全没必要这么做。
• CPU动态调频与缓存失效：现代CPU会根据负载自动降频节能，偶尔几次循环时CPU还没切换到高性能模式，耗时就会偏高；另外如果其他进程占用了CPU缓存，你的代码重新加载缓存也会导致单次耗时增加。

优化建议 #

针对这些问题，你可以调整代码和统计方式，得到更准确的结果：

• 复用Stopwatch实例：把Stopwatch的创建移到循环外面，每次用Restart()重置计时，避免重复创建对象的开销：

  var stopwatch = new Stopwatch();
  List<decimal> alltimes = new List<decimal>(1000000); // 提前设置容量，避免扩容
  for (int i = 0; i < 1000000; i++)
  {
      stopwatch.Restart();
      // my piece of code
      stopwatch.Stop();
      decimal ticks = stopwatch.ElapsedTicks;
      decimal microseconds = (ticks / Stopwatch.Frequency) * 1000000;
      alltimes.Add(microseconds);
  }
  

• 提前预热代码：在正式计时前先跑几轮空循环，让JIT完成编译，CPU切换到高性能模式：

  // 预热5轮，让JIT编译完成、CPU进入高性能状态
  for (int i = 0; i < 5; i++)
  {
      // 执行你的目标代码
  }
  

• 减少GC干扰：给List设置初始容量（比如new List<decimal>(1000000)），避免多次扩容；如果可以，用固定长度的数组代替List，进一步降低GC压力。
• 过滤异常值：统计时去掉极端值（比如去掉前0.5%和后0.5%的数据），这些都是系统干扰导致的，不能代表代码真实性能，过滤后计算的平均值会更准确。
• 用专业工具分析：如果要深入排查性能瓶颈，直接用Visual Studio的性能探查器（Performance Profiler），它能排除系统干扰，精准定位代码里的慢操作，比手动计时靠谱多了。

内容的提问来源于stack exchange，提问作者schwarz