【问题标题】:issue with .NET system.diagnostics stopwatch.NET system.diagnostics 秒表问题
【发布时间】:2026-02-17 21:10:02
【问题描述】:

我正在尝试创建一个包含秒表类使用的应用程序。

Stopwatch sw = new Stopwatch();
sw.Start();
while (play)
{
    long timer = sw.ElapsedMilliseconds;
    Debug.WriteLine(timer);
}

当我测试这个循环并检查经过的时间时,我发现程序丢失了几毫秒。

来自调试器输出的一些时钟:

31
32
33
34
35
36
37
38
40 41
42
43

关于如何解决这个问题有什么建议吗?

【问题讨论】:

  • 你如何断定它短了几毫秒?
  • 我认为您可能需要提供更多关于“丢失”毫秒意味着什么的详细信息——也许是一些输出。
  • 当我在调试器中检查计时器输出的数字不是连续的例子 1,2,3 然后它跳到 5.
  • 哦,来吧?有时,您的循环需要超过一毫秒的时间 - (对于一个简单的循环来说,这似乎太长了)您不应该期望任何操作都需要多长时间的调用之间的一致性。其他事情正在运行。如果您需要优化您的应用程序,请获取分析器,如果您不需要,请不要担心它。 CPU 不会因为运行不必要的代码而感到疲倦。
  • 这个问题涉及很多层面:D

标签: c# .net stopwatch


【解决方案1】:

您损失的毫秒数是由于您的程序不是唯一在操作系统上运行的程序。

因此,有时其他程序会得到它们的时间片,而忽略了几毫秒。

你无法“修复”它。

【讨论】:

    【解决方案2】:

    缺少毫秒?您是否希望看到每毫​​秒滴答一秒钟的条目?例如。每秒1000?如果是这样,那将永远不会发生。没有精确到 1 毫秒的计时 API。

    除了任务切换等其他操作系统进程之外,您正在输出毫秒数据的循环中执行分配和流输出这一事实意味着毫秒精度是不可能的。您需要一台专用的实时机器来实现您正在寻找的那种输出

    【讨论】:

    • 计时不准确的一个很好的例子是在 Silverlight 中进行,其准确度只有 15ms。
    • 在我的应用程序中,我需要它至少精确到 10 毫秒,但是当我增加代码行并添加一些功能时,计时器会更频繁地错过,最长可达 60 毫秒:S
    • paul 我明白你的意思,我什至尝试将应用程序优先级提高到实时并运行可执行文件,然后在终止时我将结果流式传输到文件中,但是仍然存在一些错误。真正的问题是,当我添加一些基本功能来检查计时器是否在规定的时间内,还有更多的毫秒数
    • Windows 不是实时操作系统。
    • 正如 Lasse 所说,Windows 和 C# 不是实时的,因此您不能期望这种准确性。即使具有这种准确性,您的代码在每 10 毫秒的滴答声上会运行多长时间?
    【解决方案3】:

    Debug.WriteLine 可以慢于 1 毫秒。它没有针对速度进行优化。

    您可以添加一个将消息放入列表的调用,然后在运行后将列表写入 Debug.WriteLine。 您可以添加一个后台任务将消息发送到 Debug.WriteLine。

    两者都应该防止计时器丢失滴答声。

    缺少刻度的另一个原因可能是操作系统或另一个程序在两个 Debug.WriteLine 调用之间做一些工作。它甚至可能是一台慢速机器。

    设置线程优先级或在专用机器上运行此应用程序应该会有所帮助,但在 Windows 上会出现此类计时器问题,因为它从未说过它是实时操作系统。

    【讨论】: