WindowsAPI的计时机制的比较.pptVIP

Windows API的计时机制的比较 xish 2009.12.3 基于Windows API的计时机制 clock函数（C标准库） 性能计数器（QueryPerformanceCounter） GetThreadTimes clock函数的实现方法及其效果 性能计数器的实现方法及其效果 GetThreadTimes的实现 造成计时不准的原因 中断 进程调度 计时方式（实现） 计算机体系结构本身 多核问题 处理器节能问题 性能比较 结论 除去clock函数不算，性能计数器和GetThreadTimes各有其优劣，谈不上谁好谁坏，但是如果做相对比较的话，显然性能计数器更合适——因为在一段相对固定的时间中，CPU的压力应当是一定的，其相对性能基本上没有什么变化，这就为比较提供了可能。 * * 0.155545 4.078125 GetThreadTimes 0.902138 4.22017 性能计数器 方差 平均 　 （测试代码所要拷贝的文件为59.5 MB的pdf文件，连续拷贝10次，每次结束后记录一下运行时间） （上述代码在运行时系统的负荷很高，因此波动很明显） 但是clock函数返回的是当前CPU的时间，由于windows是多任务系统，系统会在进程之间切换，于是乎，其所返回的时间差并不一定是计算所经历的时间，而有可能与CPU占用率有关，如下图，这是对同样大小的文件连续做10次复制操作所得到的时间值： 如此巨大的时间差距根本是不可能的，其原因就是在实验时其他的进程影响到了其数据的准确性。 不过经过云龙同学一提醒，我想起了还有性能计数器这样的利器。其实其实现起来并不复杂，和clock函数一样： 似乎仍旧不够准确，查网上的文摘后发现，使用QueryPerformanceCounter也是记录程序运行时经历的总时间，而不是本线程做运行的时间。其余clock的区别主要表现在QueryPerformanceCounter的精度更高而已。 那么要如何准确地测得当前程序（对于目前程序而言，也就是单线程）的运行时间呢？有办法的，可以使用GetThreadTimes方法来测得当前运行的线程的具体时间。其具体实现方法如下： 然而，使用GetThreadTimes方法所得到的结果也不能让人完全满意： 究其原因，主要是因为GetThreadTimes方法是使用系统调用NtQueryInformationThread来获取线程的TCB（线程控制块）信息，从中得到线程的内核态计数（线程在内核态经历的CPU调用次数）和用户态计数（情形类似）。必须要注意这个数值不是实时增加的，而是在时间中断发生时（约10~15ms一次）在当前线程中增加一次计数。如果我们的线程在运行的过程中被中断或者进入等待状态，则在此之前的运行结果作废（不计数了……悲剧）。于是乎就造成了结果的不准确。 而且，除了这些问题之外，由于现代计算机体系结构的变化，也造成了很多以前不会发生的错误： 多核问题 在多核处理器系统中，系统有可能会将一个线程分别进入两个处理器运行，这很有可能会导致其计数信息的紊乱。为此，有必要将其限制在一个处理器中——这并不困难，可以用SetThreadAffinityMask以及SetProcessAffinityMask方法来限制它。 处理器节能问题 随着Intel“迅驰”技术的出现，现在的很多CPU都有调频功能——也就是说，当运算负载不大的情况下，CPU会降低其主频运行——降低主频意味性能下降，从而导致运算时间延长，说实在的，暂时是找不到好方法。