Python函数性能测试需用timeit.repeat取各轮最小值以规避干扰，禁用GC仅适用于纯计算函数，setup须包含全部预处理，perf_counter更适合复杂场景并需手动预热和分位数分析。

直接用 time.time() 或 datetime.now() 测 Python 函数耗时，结果大概率不准——系统调度、GC 干扰、单次抖动都会让数字失真。

为什么不能只跑一次 timeit 就下结论

timeit 默认只执行一次（number=1），尤其对短函数，测出来可能是 0.000123 秒，但实际波动常达 ±50%。真正可靠的基准必须反映稳定态下的典型表现。

• 用 timeit.repeat(repeat=5, number=100000)：重复 5 轮，每轮执行 10 万次，取各轮最小值（避开 GC/中断干扰）
• 避免在 Jupyter 中直接调用 timeit.timeit()：魔法命令 %timeit 自动处理 setup 和预热，更接近真实环境
• 若函数含 I/O 或状态依赖（如第一次读文件快、后续走缓存），需在每次 repeat 前重置环境，比如重新导入模块或清空 functools.lru_cache

如何隔离 GC 对 CPU 密集型函数的影响

Python 的垃圾回收器可能在任意时刻触发，尤其在大量创建临时对象时，导致某一轮 timeit 突然变慢，拉高整体方差。

• 在 setup 字符串或 globals 中禁用 GC：import gc; gc.disable()，测试完再 gc.enable()
• 仅对纯计算类函数（如数值运算、字符串拼接）禁用 GC；含 list.append() 或字典操作的函数，禁用后反而失真
• 用 gc.get_count() 检查是否真有代际回收发生，别盲目禁用

对比不同实现时，setup 必须完全一致

把初

始化逻辑写进被测函数里，等于把“建表”时间也算进“查表”性能里，常见于测试 dict 查找 vs list 遍历时漏掉 data = list(range(10000)) 的构建开销。

• 所有预处理（数据生成、对象实例化、模块导入）必须放在 setup 参数中，而非被测语句内
• 用 lambda 包裹被测代码时，确保闭包变量不意外触发额外查找（比如用 locals() 传参比自由变量更可控）
• 测试类方法时，setup 应包含 obj = MyClass()，被测语句写成 obj.method()，而非 MyClass().method()（后者多了一次实例化）

真实场景下，perf_counter 比 timeit 更灵活但更易出错

当需要测带异步、多线程、或依赖外部状态（如数据库连接池）的流程时，timeit 的沙箱模型反而碍事，此时得用 time.perf_counter() 手动控制，但必须自己处理冷启动和预热。

• 首次调用前先空跑 3–5 次（不计时），让 JIT（如 PyPy）、CPU 频率、OS 页面映射进入稳态
• 用 perf_counter_ns()（Python 3.7+）替代浮点秒数，避免浮点精度丢失（尤其微秒级函数）
• 记录每次耗时到列表，剔除首尾 10% 极端值再取均值，比单纯用 min() 更抗突发抖动

最常被忽略的不是工具用法，而是测试目标本身：你到底想回答“这个函数平均多快”，还是“它在 P99 延迟下是否达标”——前者看中位数，后者必须采样足够多轮并统计分位数，而默认的 timeit 不提供这种输出。