这个想法是，一个现有的项目相当频繁地使用timeGetTime（）（用于Windows目标）。
milliseconds = timeGetTime();
现在，这可以被replace
double tmp = (double) lpPerformanceCount.QuadPart/ lpFrequency.QuadPart; milliseconds = rint(tmp * 1000);
通过使用对QueryPerformanceCounter（）和QueryPerformanceFrequency（）的单个调用来取得lpPerformanceCount.QuadPart和lpFrequency.QuadPart。
我知道Windows的内部是一种巫术，但是有人可以破译其中哪一个更准确或者更多的开销？
Windows中terminal应用程序中的C颜色文本
如何确定gcc默认将哪些命令行选项传递给ld？
僵尸进程
sem_post / sem_wait比pthread_mutex_lock / pthread_mutex_unlock快得多吗？
在Linux上共享串行端口
我怀疑准确性可能相同，但QueryPerformanceCounter可能有较less的开销。 但是我没有硬数据来支持它。
如果情况正好相反，我当然不会感到惊讶。
如果开销很小，我会更关心精度是否有差异。
从MysqL获取UTF-8数据到Linux C ++应用程序
如何copy_to_user一个string和在linux内核读取函数中使用offp
fflush，fsync和sync与内存层
SWIG python模块创build问题
窗口上的句柄的来源
timeGetTime（）的准确性是可变的，基于上次使用的timeBeginPeriod。 它永远不会比毫秒更好。 QueryPerformanceCounter也是可变的，这取决于硬件支持。 它永远不会比一微秒更差。
他们都没有明显的开销，QPC可能会更重一点。 从你的问题来看，这对你是否重要？ 我怀疑它，但措施。 与QPC。
请注意：QueryPerformanceCounter可能取决于处理器。 如果你的线程抓取一个cpu上的perf计数器，并在再次抓取之前结束到另一个cpu上，则结果可能不可靠。 请参阅MSDN条目 。
准确性在QPC上更好。 timeGetTime在1-10ms范围内精确（其分辨率不会超过1ms），而QPC可以在微秒范围内给出准确度。
开销不一。 QPC使用最好的硬件计时器。 这可能是内置在cpu中的轻量级内存，或者可能不得不跑到主板上，这会增加显着的延迟。 不得不通过一个驱动程序来纠正定时器硬件的错误。
但是既不昂贵也不昂贵。 如果你不打算每秒钟调用这个定时器数百次，那么对于这两者来说开销都是微不足道的。
我们更新了QueryPerformanceCounter的文档，这应该有助于回答上述问题。 请参见
http://msdn.microsoft.com/en-us/library/windows/desktop/dn553408(v=vs.85).aspx
埃德布里格斯微软公司
QueryPerformanceCounter并不完全给你一个时间。 为了将其值转换为时间度量，您必须使用QueryPerformanceFrequency ，它应该让您知道计数器以何种速率递增。 但频率值或多或少是一个估计值。 计数器的频率可以随底层硬件和操作系统的版本而变化。 但这不应该算是一个常数。 它有一个偏移量，有时会受到热漂移的影响。 说，我会建议小心使用QueryPerformanceCounter 。
有些仍然将accuracy与granularity混合在一起。 QueryPerformanceCounter具有更好的粒度，而timeGetTime具有更好的精度。
但是，最快的来源是GetSystemTimeAsFileTime ，它以100ns为单位返回一个时间值。 但其粒度不是 100ns。 其粒度取决于timeGetDevCaps的结果和timeBeginPeriod的设置。 正确设置后者可以导致大约10000的颗粒度，对应于大约1ms。
我在这里写了更多的细节。
