Python 性能测试的正确基准设计

time.time() 不适合性能基准测试，因其精度低、受系统干扰大；应使用 time.perf_counter()，配合多次运行、timeit 模块合理配置、控制输入变量、避免缓存效应，并优先选用 pytest-benchmark 等专业工具。

为什么 time.time() 不适合做 python 性能基准

它精度低、受系统干扰大，尤其在函数执行快于毫秒级时，测出来经常是 0.0 或抖动剧烈，根本没法比。windows 上默认只有 15ms 分辨率，linux 虽好些，但依然混着进程调度、GC、CPU 频率缩放等噪声。

实操建议：

• 用 time.perf_counter() —— 它专为性能测量设计，单调、高精度、不受系统时间调整影响
• 避免单次调用：哪怕函数很快，也要跑足够多轮（比如 range(1000)），再取平均或中位数
• 别在 jupyter 或 ide 的交互式环境里直接测：启动开销、缓存状态、后台线程都会污染结果

用 timeit 模块时的三个关键配置点

timeit 是标准库里最靠谱的轻量基准工具，但它默认行为容易误导人——比如自动重复 100 万次却不告诉你实际耗时是否稳定，或者把 setup 代码也计入耗时。

实操建议：

• 显式指定 number 和 repeat：例如 timeit.timeit(stmt, setup, number=10000, repeat=5)，然后取 min(...) 而非平均值（排除 GC 突发、缺页等毛刺）
• setup 里只放真正前置依赖，别塞初始化逻辑：比如测试 json.loads，setup 只需 "import json"，别把待解析字符串也放进去
• 命令行用法更干净：python -m timeit -s "import re" "re.search('a+', 'aaaa')"，避免 shell 环境变量或 IDE 插件干扰

当你要对比两个算法，但它们有不同输入规模时

直接比“谁快 10ms”没意义。比如一个算法在小数据上快，大数据上慢，或者反过来。不控制变量，基准就只是个幻觉。

实操建议：

• 固定输入生成逻辑：用 random.seed(42) + 同一长度的 list(range(n)) 或 bytes(n)，确保每次 run 输入完全一致
• 做多组 n 测试：比如 n = [100, 1000, 10000]，画出时间随规模变化的趋势，看是 O(n) 还是 O(n²)
• 警惕“缓存效应”：如果反复用同一对象（比如同一个 dict），第二次以后可能走 CPU 缓存路径；应每次新建输入，或用 gc.collect() 前置清理

为什么 pytest-benchmark 在项目里更可靠

手写 timeit 很快会失控：要管 warmup、统计分布、结果输出格式、跨机器可比性……而 pytest-benchmark 把这些都封装好了，且天然和测试流程集成。

实操建议：

• 安装后直接写测试函数，用 benchmark fixture 调用目标函数：result = benchmark(my_func, arg1, arg2)
• 它默认做多次预热 + 多轮采样，并报告 mean、stddev、outliers，一眼看出稳定性
• 注意 benchmark.group 参数：把同类函数（比如不同排序实现）归一组，报告时自动横向对比，避免手动算倍率

真实项目里，最常被忽略的是「冷启动偏差」：第一次运行总会慢一点，尤其是涉及 import、JIT（如 PyPy）、或首次内存分配。不管用什么工具，至少预热一轮再开始计时——这点没人帮你自动做。