.net - .NET Stopwatch 类有这么糟糕吗？

Question

我正在制作一个需要非常严格的计时的应用程序，而 Stopwatch 类是完美的解决方案。然而，我注意到有时，当在小型平板电脑上运行时，秒表值相差很大。我添加了一些调试打印输出，每 200 毫秒左右监控一次秒表的值:

0:00:197
0:00:502
0:00:702
...
0:03:356
0:12:93
0:13:21
0:13:421
...

它怎么可能从 ~3 秒跳到 ~13 秒？我现在发现底层函数 QueryPerformanceCounter() 有问题( Beware of QueryPerformanceCounter() )，但我感觉到这里还发生了其他事情。

任何见解都值得赞赏。

更新:

这是我的代码的更多细节:它非常简单。它是一个 WPF 应用程序，在启动时创建一个新的 Stopwatch 对象，然后通过 Start() 启动它。然后我创建一个 DispatcherTimer，如下所示:

displayTimer = new DispatcherTimer(); 
displayTimer.Tick += display_Tick; 
displayTimer.Interval = DISPLAY_INTERVAL_TIMESPAN; 

其中时间跨度为 200 毫秒。我的调试代码只是在每次 dispatchTimer 滴答时打印出 Stopwatch 对象的值。

更新2:

一篇有趣的 Microsoft 支持文章是 Performance counter value may unexpectedly leap forward 。

Answer 1

更新(查看日志后)

正如您已经提到的，Stopwatch 类使用 QueryPerformanceCounter下面的功能。在 MSDN 的备注部分中说:

On a multiprocessor computer, it should not matter which processor is called. However, you can get different results on different processors due to bugs in the basic input/output system (BIOS) or the hardware abstraction layer (HAL). To specify processor affinity for a thread, use the SetThreadAffinityMask function.

当您使用 Dispatcher 时，QueryPerformanceCounter 可能不会在每次查询耗时时在同一个 CPU 上执行。

您可以通过为您的进程指定处理器关联来检查 MSDN 中提到的问题是否是您的问题的原因，例如通过使用 start 命令调用可执行文件。对我来说，10 秒似乎是 CPU 之间的很大延迟，但文档对于差异可能有多大非常模糊。以下命令会将您的应用程序绑定(bind)到第一个 CPU:

> start.exe /AFFINITY 1 program.exe

如果这可以解决问题，您可能需要查看建议的解决方法，即在查询 Stopwatch 对象之前调用 SetThreadAffinityMask 函数。

您的评论表明您正在使用 WPF DispatcherTimer。 documentation该类的状态:

Timers are not guaranteed to execute exactly when the time interval occurs, but they are guaranteed to not execute before the time interval occurs. This is because DispatcherTimer operations are placed on the Dispatcher queue like other operations. When the DispatcherTimer operation executes is dependent on the other jobs in the queue and their priorities.

这意味着计时器事件可能会延迟到达，特别是当调度程序忙于其他任务时。您是否在调度程序队列中放置了其他内容来阻止事件提前触发？