Python性能基准测试核心是可重复、可比较地量化执行效率，重在识别瓶颈、验证优化、支撑选型；需明确定义场景、控制环境变量、选用合适工具、关注统计显著性，并结合业务上下文解读结果。
Python性能基准测试的核心是用可重复、可比较的方式量化代码执行效率，重点不是追求绝对数值，而是识别瓶颈、验证优化效果、支撑技术选型决策。
明确测试目标和场景
基准测试前必须定义清楚“比什么”和“在什么条件下比”。比如：是比两个算法处理10万条日志的耗时？还是比不同JSON库解析大文件的内存占用？不明确场景会导致结果失真。建议优先覆盖真实业务中的典型输入规模（如中等数据量+高频调用路径），避免只测极端小数据或理想缓存命中情况。
- 记录Python版本、操作系统、是否启用JIT（如PyPy）、是否关闭GC（
gc.disable()）等关键环境信息 - 对I/O密集型任务，注意磁盘缓存、网络延迟干扰；CPU密集型任务需固定CPU频率或隔离核心
- 单次运行易受系统抖动影响，应多次运行取中位数或使用
timeit自动循环
选用合适工具，避免常见陷阱
timeit适合短小函数的微基准测试，pytest-benchmark适合项目级集成对比，line_profiler和memory_profiler用于定位热点行和内存泄漏。不要用time.time()粗略相减——它精度低、易受系统调用干扰。
- 用
timeit.repeat(repeat=5, number=10000)而非timeit.timeit()单次测量 - 避免在测试代码中包含导入语句（除非测的是模块加载开销），否则会污染结果
- 对异步代码，用
asyncio.run()包装并确保事件循环干净启动，不复用已有loop
对比时控制变量，关注统计显著性
两个实现A和B的耗时分别为12.3ms和11.8ms，表面快4%，但若标准差达±0.8ms，差异可能无统计意义。建议用scipy.stats.ttest_rel做配对t检验，或直接观察重叠的置信区间。
- 每次对比只改一个变量（如仅替换算法，不同时升级依赖版本）
- 用
perfplot画出不同输入规模下的性能曲线，判断复杂度是否符合预期 - 记录warm-up轮次（前几次运行常含编译/
缓存初始化开销），正式计时从第N次开始
缓存初始化开销），正式计时从第N次开始结果解读要结合上下文
快20%的优化在QPS 5000的服务里可能提升不大，但在每秒处理百万消息的流式管道中就是关键。同样，内存节省30MB对桌面脚本无关紧要，对容器化部署却可能决定能否缩容。
- 标注“相对提升”和“绝对收益”，例如：“响应延迟从87ms降至69ms（↓21%，绝对减少18ms）”
- 注明是否牺牲了可读性、可维护性或兼容性——性能不该以不可维护为代价
- 对C扩展、多进程等方案，额外测试启动开销、进程间通信成本等隐性代价
