• Windows下获取高精度时间注意事项 [转贴 AdamWu]


    花了很长时间才得到的经验,与大家分享。

    1. RDTSC - 粒度: 纳秒级 不推荐
    优势: 几乎是能够获得最细粒度的计数器
    抛弃理由:

     A) 定义模糊
     - 曾经据说是处理器的cycle counter,但是后来似乎又不是了。
    有的机器上每秒的TSC增长值等于CPU频率,有的却是一个不对应任何配置的数。到底是什么,Intel也没解释清楚。

     B) 不准确
     - 这是最重大的缺陷。再细的粒度,不准的话也没用,至少不能当时间用。
    在有的CPU上,特别是支持变频技术的笔记本CPU上,TSC增长值会随着CPU的频率改变。忙的时候跑得快,闲得时候跑得慢。

    2. QueryPerformanceCounter - 粒度: 1~100微秒级 不推荐
    优势: 尽管比RDTSC粒度稍低,但是不存在RDTSC在变频CPU上的问题。
     知道这个API的人估计都倾向于用这个,因为M$对这个API给出了比较明确的定义,就是每秒钟某个计数器增长的数值。
    抛弃理由: 还是不准确

    尽管没有源代码,但是从M$的帮助文档和知识库可以了解到,PerformanceCounter是依赖于主板上与PCI设备有关联的硬件。这就意味着,PerformanceCounter的结果还是会受到硬件频率,特别是总线频率的影响。

    事实上,我在EeePC上测试的时候就发现,系统采用节能模式的时候PerformanceCounter出来的结果老是偏慢很多,超频模式的时候又偏快,而且用电池和接电源的时候效果还不一样!

    3. timeGetTime - 粒度: 毫秒级 推荐
    尽管粒度进一步降低,但是其无与伦比的优势就是,准确。
    在任何机器上返回的都是当前系统的启动时间,精确到1毫秒。

    使用注意事项:

     A) 在NT系统上(据说)默认精度为10ms,但是可以用timeBeginPeriod来降低到1ms
     B) 返回的是一个32位整数,所以要注意大约每49.71天会出现归零(不像前两个是64位数,要几百年才会归零)。

    http://www.cnblogs.com/AnyDelphi/archive/2009/05/14/1456716.html

  • 相关阅读:
    字符编码 进制转换
    Android工具HierarchyViewer 代码导读(1) 功能实现演示
    jQuery中的bind(), live(), on(), delegate()
    [转]ActionScript3.0中XML处理方法
    Pane和Panel的区别
    [转]在命令行中编译运行Java Applet
    [转]关于五险一金,你知道多少?
    [转]ActionScript3.0对象深复制
    [转]用Flashbug调试Flash
    [转]用EditPlus搭建简易的Java开发环境
  • 原文地址:https://www.cnblogs.com/findumars/p/6280434.html
Copyright © 2020-2023  润新知