/usr/bin/time与Python自测量运行时间偏差的原因问询

嘿，这个问题看起来有点反直觉对吧？咱们一步步拆解清楚：

首先得搞懂两个时间测量的本质差异：

• 你用的/usr/bin/time工具，它测量进程运行时间的时候，用的是系统单调时钟（CLOCK_MONOTONIC）——这个时钟是只增不减的，完全不受系统时间调整（比如NTP同步、手动改时间）的影响，它测的是进程从启动到退出的真实流逝时长。
• 而你的Python脚本里，psutil.Process().create_time()和time.time()用的都是系统墙上时钟（CLOCK_REALTIME）——这个时钟就是你系统显示的当前时间，会被NTP同步、手动修改等操作改变。

那回到你的例子，出现这种偏差的核心原因大概率是：在Python进程创建后、脚本执行到time.time()这一行前，你的系统时间被往后调整了大约0.8秒。

举个具体场景来理解：

1. 系统当前时间是10:00:00.000，/usr/bin/time启动并fork出Python进程，此时Python进程的create_time()记录的就是这个时间点。
2. 紧接着，NTP同步把系统时间往后拨了0.8秒，变成10:00:00.800。
3. Python进程继续执行，花了0.03秒的真实时长运行到time.time()这一行，此时墙上时间是10:00:00.830。
4. 脚本计算10:00:00.830 - 10:00:00.000 = 0.830秒（和你看到的0.820秒接近），但/usr/bin/time用单调时钟测到的真实运行时长只有0.03秒——这就是偏差的来源。

另外还有一种小概率情况：如果你的Python进程被某种机制预创建了（比如某些服务的预加载池），进程被fork出来后处于休眠状态，过了0.8秒才被调度去执行你的脚本。这种情况下，create_time()是进程被fork的时间，而time.time()是脚本实际执行到那一行的时间，差值就是休眠的0.8秒加上实际执行的0.03秒；不过这种情况里/usr/bin/time的计时应该也会包含休眠时间，所以可能性相对较低。

你可以用下面的方法验证这个推测：把脚本改成用基于单调时钟的函数来计算时间差，比如：

import time
start_monotonic = time.monotonic()
print("startup took %.3fs" % (time.monotonic() - start_monotonic))

或者用time.perf_counter()，这两个都是不受系统时间调整影响的，测出来的结果应该和/usr/bin/time的输出接近。

内容来源于stack exchange