要想真正有效地测试、优化程序性能——特别是为Windows服务器开发的多线程程序，操作系统提供的标准时钟是不够的，必须使用解析度更高的时钟。本文介绍了如何访问处理器的十亿分之一秒级别的时钟，极大地提高代码性能测试的速度和精度。

一、获取计时数据

和其他Windows服务器一样，在Windows 2003 Server上能发挥性能优势的是多线程程序。Windows 2003 Server支持各种多处理器系统，同时也能在单处理器的P4系统上运行。对于单处理器P4系统，Windows 2003 Server将发挥出Intel超线程技术提供的各种硬件线程执行引擎的优势。

开发服务器应用的人都知道，之所以要开发并行程序，真正的原因只有一个——性能。然而，众所周知，性能改善是一个比较模糊的目标，因为多线程代码的性能通常只能靠经验估计。在单线程程序中，性能改进程度一般可以精确地预知，例如减少了多少指令和延迟较高的操作，但多线程代码不同，Windows平台中线程调度是不确定的，也是说，在Windows中应用程序可以要求调度程序运行线程，但调度程序何时（是否）运行线程则远远超出了应用程序代码的控制范围。

在测试性能时，开发者很快会遇到一个问题，这是Windows内建的标准时钟实在不够精确，其可靠测量事件时间的解析度很难高于一秒，这样，要确定一个代码片段是否真正得到优化很困难了。如果一定要用Windows的标准时钟进行测试，必须利用循环让代码运行几百万次，才能获得有效的时间数据。绝大多数情况下，使用这类循环意味着修改应用程序。

其实，还有更好的办法，这是Win32高解析度时钟，涉及的函数有两个：QueryPerformanceCount()，QueryPerformanceFrequency()。在Intel系统中，从P II开始，这些函数依赖于Pentium芯片内建的一个计数器。当一个Intel系统启动时，一个64位的寄存器跟踪着消逝的时钟周期，这个计数器提供了解析度极高的计时设备。

整个64位寄存器都要用到。32 bit的整数大约能计数20亿，对于当前每秒运行20-30亿个周期的处理器，32 bit的计数器会在一秒或更少的时间内溢出，64 bit的计数器则能容纳这些秒数的20亿倍，按20亿秒计算是约63年——可以相信，这已经远远超出测量任何程序的要求了。

要对一个事件进行计时，只需获得事件开始之前、结束之后的时钟计数。下面的代码不依赖于Win32（即，从C/C++直接访问），稍后我们再看看操作系统提供的函数。我们首先定义一个数据结构，然后再来看填写该结构的代码：

typedef struct _BinInt32 { __int32 i32[2];
 }
BigInt32; typedef struct _BigInt64 { __int64 i64
;
} BigInt64; typedef union _bigInt { BigInt32 int32val
; 　
BigInt64 int64val
;
}
BigInt
;

下面的代码从操作系统获得时钟计数器的高位和低位，分别填写__int64数据的两个32 bit部分：

BigInt start_ticks， end_ticks
;
 _asm {
RDTSC mov start_ticks.int32val.i32[0]， eax
 mov start_ticks.int32val.i32[4]， edx
}

这段代码能够在Visual Studio .NET 2003中顺利运行，在以前的C/C++编译器中也应该没有问题。RDTSC（ReaD Time Stamp Counter）是一个汇编指令，它的功能是把时间戳计数器的内容装入EAX和EDX寄存器。执行上述代码后，start_ticks包含了完整的时钟计数。再次调用上面的代码，把start_ticks替换成end_ticks，再从end_ticks减去start_ticks，得到了两次调用期间流逝的时钟周期。

要输出这个_int64值，可以使用下面的printf()掩码：

printf ( "Function used %I64Ld ticks "，

end_ticks.int64val.i64 - start_ticks.int64val.i64 );

Win32函数QueryPerformanceCounter()的功能也大致相似，它的参数是一个指向计数器变量的长指针。如果函数调用失败，它返回0（实际上是FALSE）。然而，上面提供的代码突破了Windows调用的黑箱，即使在非Windows的Intel系统上，也能发挥同样的功能。