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)) 的构建开销。
立即学习“Python免费学习笔记（深入）”；
- 所有预处理（数据生成、对象实例化、模块导入）必须放在
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 不提供这种输出。
