关于测试程序多次执行中GetTickCount()与timeGetTime()延迟变化的问询

你观察到的这个多次执行测试时两个API延迟变化的现象，完全符合Windows系统计时器的底层逻辑，咱们来拆解清楚：

• 核心差异：两种API的计时器依赖不同

  • GetTickCount()（现在更推荐用GetTickCount64()避免溢出）依赖系统的基础时钟中断，默认频率大概是60Hz，对应分辨率就是约15.625ms（也就是你说的16ms）。它的数值不是连续递增的，而是每16ms左右跳一次，每次直接加16。
  • timeGetTime()属于多媒体计时器框架，它的分辨率是可以手动调整的——通过调用timeBeginPeriod(1)，你把它的分辨率拉到了1ms，这意味着系统会把多媒体计时器的中断频率提高到1000Hz，让这个API的数值每1ms更新一次。

• 你的假设完全成立：高分辨率确实会缩短计数器递增间隔
  当你调用timeBeginPeriod(1)后，系统会调整后台负责更新timeGetTime()计数器的线程调度策略，让它被唤醒的间隔从默认值（比如16ms）缩小到1ms，所以计数器连续两次递增之间的系统睡眠时间自然就变短了。而GetTickCount()不受这个设置影响，依然按16ms的节奏跳变，所以每次采样时两者的差值（延迟）就会出现波动——毕竟timeGetTime()的更新更频繁，每次抓值时它和GetTickCount()的“相对位置”都不一样。

• 几个实用的注意点

  • 高分辨率计时器是有代价的：频繁开启1ms分辨率会让CPU更频繁响应中断，增加系统整体开销。所以建议只在需要高精度计时的代码段前后调用timeBeginPeriod()，用完立刻用timeEndPeriod(1)恢复默认设置。
  • 如果需要微秒级的高精度计时，timeGetTime()还是不够看，可以试试QueryPerformanceCounter()和QueryPerformanceFrequency()，这俩基于硬件计数器，分辨率能达到微秒甚至纳秒级，适合对时间精度要求极高的场景。

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