perf_counter 是 Python 中最可靠的高精度计时工具，跨平台、单调递增、纳秒级分辨率，适合测量代码真实耗时；应结合多次运行、最小值策略、GC 控制与预热来提升准确性。
perf_counter 是 Python 中最可靠的高精度计时工具，它不受系统时间调整影响，适合测量代码段真实耗时。但直接用它“套两行代码”容易踩精度陷阱或忽略上下文干扰。
为什么不用 time.time() 或 time.clock()？
time.time() 受系统时钟同步（如 NTP）影响，可能跳变；time.clock() 在 Python 3.8+ 已被移除，且历史行为因平台而异（Windows 返回 CPU 时间，Unix 返回进程时间）。perf_counter() 是唯一跨平台、单调递增、纳秒级分辨率的推荐方案。
- 它返回的是“从某个未指定起点开始的单调时钟”，只关心差值，不关心绝对时间
- 在 Linux/macOS 上通常基于
CLOCK_MONOTONIC，Windows 上基于QueryPerformanceCounter - 实际分辨率取决于硬件和 OS，但 Python 保证其精度 ≥
time.time()
怎么写才真正测准一段代码？
单次调用 perf_counter() 差值可能受 JIT、GC、CPU 频率波动干扰，尤其对毫秒级以下操作。真实场景应结合多次运行与最小值策略。
- 避免在循环外只测一次：用
for _ in range(N)多次执行目标代码，取min()而非mean()—— 最小值更能反映“无干扰下的最佳性能” - 手动触发 GC：在每次循环前加
gc.collect()，防止某次运行因垃圾回收拖慢结果 - 预热：首次运行常含解释器开销（如字节码编译），建议丢弃前 1–2 次结果
- 示例片段：
import time import gc <p>def benchmark(func, <em>args, repeats=5): times = [] for i in range(repeats + 2): # 多跑两次预热 gc.collect() start = time.perf_counter() func(</em>args) end = time.perf_counter() if i >= 2: times.append(end - start) return min(times)
perf_counter 和 perf_counter_ns 有什么区别？
perf_counter_ns() 是 Python 3.7+ 引入的纳秒级整数接口，返回 int 类型的纳秒值；perf_counter() 返回 float 秒值（底层仍是纳秒，但转为 float 可能损失精度）。
立即学习“Python免费学习笔记（深入）”；
- 对微秒级以下差异敏感时（比如对比两个极短函数），优先用
perf_counter_ns()避免浮点舍入误差 - 计算差值后若需转为毫秒，用
(end_ns - start_ns) / 1e6，别用round()截断——会掩盖真实分布 - 注意：即使返回整数，也不能假设“1 纳秒=1 个 CPU 周期”，现代 CPU 有乱序执行、缓存命中等复杂因素
哪些情况会让 perf_counter 结果失真？
它本身没问题，但测量方式或环境会让数据不可靠：
- 在 Jupyter 或 IPython 中直接测单行表达式：前后存在隐式开销（如
_变量赋值、显示逻辑） - 测量含 I/O 的代码（如
print()、文件读写）：实际耗时主要由系统调度和设备决定，perf_counter只是忠实地记录，不代表 CPU 计算效率 - 没禁用自动优化：如果测的代码段被 Python 解释器识别为无副作用（如纯计算且结果未使用），可能被跳过 —— 务必确保结果被显式引用（例如
result = my_func(); assert result is not None） - 多线程/多进程环境下，
perf_counter仍有效，但无法区分是本线程耗时还是被调度抢占的时间 —— 这时候需要threading.get_ident()配合日志，或改用process_time()
真正难的不是调用 perf_counter()，而是控制变量、排除噪声、理解你到底想回答什么问题。比如“这个函数快不快”和“它比另一个快多少”需要完全不同的测量设计。
