我想知道 System.Timers 中 Timer 类的精度是多少,因为它是双精度的(这似乎表明您可以有几分之一毫秒)。它是什么?
6 回答
Windows 桌面操作系统在大约 40 毫秒以下确实不准确。操作系统根本不是实时的,因此呈现出显着的非确定性抖动。这意味着虽然它可能会报告低至毫秒甚至更小的值,但您不能真正指望这些值真正有意义。因此,即使将 Timer 间隔设置为某个亚毫秒值,您也不能依赖设置和触发之间的时间来真正实现您所说的您想要的。
再加上你正在运行的整个框架是不确定的(GC 可能会在 Timer 应该触发的时候暂停你并进行收集)并且你最终会承担大量的风险来尝试做任何事情时间紧迫。
System.Timers.Timer 很奇怪。它使用 double 作为间隔,但实际上在其上调用 Math.Ceiling 并将结果转换为 int 以与底层 System.Threading.Timer 一起使用。它的理论精度是 1 毫秒,您不能指定超过 2,147,483,647 毫秒的间隔。鉴于此信息,我真的不知道为什么使用双精度作为间隔参数。
几年前,我发现它可以精确到大约 16 毫秒……但不幸的是,我不记得细节了。
您可以通过执行一个不断采样结果持续时间并检查其步进的粒度的循环,自己轻松地找到这一点。
定时器分辨率下降到 1ms 范围内,无需太多实施工作。我刚刚描述了这个答案double
精确的原因. 将系统配置为以每秒 1024 次中断运行(使用多媒体计时器 API)时,中断之间的时间为 0.9765625 毫秒。时序问题的标准分辨率是 100ns。这些值存储为整数。值 0.9765625 无法在不丢失 100 ns 分辨率的整数精度的情况下存储。最后一位数字 (5) 代表 500 ps。因此,分辨率必须高出三个数量级。以 100 ps 分辨率将这些时间值存储在整数中是没有希望的,因为 100 ps 分辨率下的 8 字节整数将仅包含大约 21350 天或大约 58 年。这个时间跨度太短,无法被任何人接受(记住千年虫方案!)。
请参阅链接到的答案以了解有关详细信息的更多信息。
我比较System.Timers.Timer
了System.Threading.Timer
- 他们都给出了大约 8..16 毫秒的系统误差,尤其是在小间隔(1000..6000 毫秒)。定时器例程的每个后续调用都随着第一次调用的间隔增加而发生。例如,间隔为 2000 毫秒的计时器会在 2000、4012、6024、8036、10048 毫秒等时间触发(从Environment.TickCount
和获得的时间戳Stopwatch.ElapsedTicks
,都给出相同的结果)。