为什么 time.clock() 在 Windows Server 2008 X64 上返回如此大的值答案

【问题标题】：Why time.clock() returns such a large value on Windows Server 2008 X64为什么 time.clock() 在 Windows Server 2008 X64 上返回如此大的值
【发布时间】：2010-03-07 08:49:01
【问题描述】：

我在不同的机器上运行了以下脚本，得到了完全不同的结果。经过的 time.clock() 太大了。

脚本：

#------------------------------------------------------------------------------------
import time
start_clock = time.clock()
time.sleep(60)
end_clock = time.clock()
print "Sleep Clock = ", str(end_clock - start_clock)

start_time = time.time()
time.sleep(60)
end_time = time.time()
print "Sleep Time = ", str(end_time - start_time)
#-------------------------------------------------------------------------------------

输出：

Instance (Windows Server 2008, X64):
Sleep Clock =  938.306471633
Sleep Time =  60.0119998455

Local Machine (Windows Vista, X86):
Sleep Clock =  59.9997987873
Sleep Time =  59.996999979

以下结果让我很困惑：
睡眠时钟 = 938.306471633

附注：我没有在其他 X64 操作系统上测试过。此 Windows Server 2008 是一个正在运行的 Amazon 实例。

【问题讨论】：

仅供参考，我在 Win7 x64 机器上运行了代码，结果 time() 和 clock() 方法的值都接近 60。
您是否始终如一地获得这些值？有没有可能在您的测试期间更新了时钟，也许是网络时间服务启动了？
谢谢菲利普。结果似乎不是很稳定。我记得可能是 700 左右，而不是总是接近 900。我不确定是不是因为我在 Amazon 虚拟机上运行了这个脚本。

标签： python time

【解决方案1】：

每the docstime.clock

在 Windows 上，此函数返回自挂钟以来经过的秒数首先调用此函数，作为浮点数，基于 Win32 函数 QueryPerformanceCounter()。

所以我的（盲目的，即我从未见过亚马逊的 Windows 虚拟化代码！-）猜测亚马逊的虚拟化并没有深入到足以欺骗QueryPerformanceCounter（这是一个非常低级的，低开销功能）。欺骗time.time（在虚拟化管理程序中）更容易（并且更常见）。

你知道会发生什么吗？在 Microsoft 的 Azure 以及其他非 Microsoft 虚拟器（如 Parallels 或 VMWare）上？看到在每种情况下执行的“诡计”（深度虚拟化）的数量有不同的“深度”，我不会感到惊讶。（我不怀疑对这一观察结果的解释一定与虚拟化有关，尽管我在上面所做的具体猜测可能存在缺陷）。

尝试（同样，在各种不同的虚拟器上）一个只执行QueryPerformanceCounter 的小型 C 程序也会很有趣，只是为了确认 Python 的运行时与案例无关（我相信是的，通过检查运行时的源代码，但确认不会有什么坏处——不幸的是，我无法访问自己尝试所需的资源）。

【讨论】：