引言
本文基于 《Effective Python: 125 Specific Ways to Write Better Python, 3rd Edition》第 11 章：性能中的Item 93: Optimize Performance-Critical Code Using timeit Microbenchmarks，旨在总结对 timeit 模块的使用方法和技巧，并结合个人开发经验进行延伸思考。在实际开发中，我们经常遇到这样的场景：程序运行速度不理想，但又不知道瓶颈在哪？或者即使找到热点函数，也难以判断哪种优化方案更优？此时，微基准测试工具就派上用场了。
timeit 是 Python 标准库中的一个模块，专门用于测量小段代码片段的执行时间。它不仅能帮助我们比较不同实现方式的性能差异，还能作为持续优化过程中的重要参考指标。尤其在处理性能敏感代码（如高频计算、数据结构选择等）时，掌握 timeit 的使用技巧至关重要。
一、如何准确测量一段代码的执行时间？
在编程实践中，我们常常需要知道某段代码运行多长时间，以便进行性能调优或算法对比。最简单的方式是手动记录开始时间和结束时间：
import time
start = time.time()
# 要测量的代码
end = time.time()
print(f"耗时: {end - start} 秒")
这种方式虽然直观，但在面对微基准测试时存在明显局限：系统噪声干扰大、单次测量误差高、无法排除初始化开销。例如，如果你只测量一次循环加法操作的时间，结果可能受其他进程影响而波动极大。
这时就需要更专业的工具——timeit 模块。它默认会重复执行 100 万次指定的代码片段，并返回总耗时（秒），从而减少随机性带来的误差。例如：
import timeit
delay = timeit.timeit(stmt="1 + 2", number=1_000_000)
print(f"1 + 2 执行 100 万次耗时: {delay:.6f} 秒")
输出可能是：
1 + 2 执行 100 万次耗时: 0.043768 秒
通过除以迭代次数，我们可以得到每次操作的平均耗时（单位为纳秒）：
avg_time = (delay / 1_000_000) * 1e9
print(f"单次加法耗时: {avg_time:.2f} 纳秒")
这样得出的结果更加稳定可靠，适合用于后续对比分析。
二、为什么不能只测少量迭代次数？
有些开发者可能会觉得：“我只想知道这段代码大概跑多久，没必要跑一百万次。”这种想法看似合理，但实际上非常危险。因为现代操作系统是一个多任务环境，CPU 时间片被多个进程共享，任何一次中断都可能导致测量结果失真。
举个例子，如果我们只运行 100 次加法操作：
delay = timeit.timeit(stmt="1 + 2", number=100)
avg_time = delay / 100 * 1e9
print(f"错误使用 - 迭代次数太少: {avg_time:.2f} 纳秒")
输出可能是：
错误使用 - 迭代次数太少: 7.50 纳秒
看起来很快，但这个结果很可能只是“碰巧”没有受到系统负载的影响。一旦有其他程序占用 CPU，这个值就会剧烈波动，甚至出现数量级的变化。
因此，建议始终使用足够大的迭代次数（如 100 万次），并配合平均值计算来获得更精确的结果。此外，timeit 模块还会自动禁用垃圾回收器，进一步减少外部因素干扰。
三、如何隔离初始化逻辑以提高测试准确性？
在很多情况下，我们需要测试的是某个核心操作的性能，而不是整个函数或脚本的运行时间。比如查找一个数字是否存在于一个大型列表中：
def test_list_lookup():
numbers = list(range(10000))
random.shuffle(numbers)
probe = 7777
return probe in numbers
如果直接使用 timeit 测量该函数的执行时间，那么列表创建和打乱顺序的操作也会被计入，导致结果偏差。正确的做法是将这些初始化步骤放在 setup 参数中：
count = 100000
delay = timeit.timeit(
setup="""
import random
numbers = list(range(10000))
random.shuffle(numbers)
probe = 7777
""",
stmt="probe in numbers",
globals=globals(),
number=count,
)
avg_time = (delay / count) * 1e9
print(f"list 成员查找耗时: {avg_time:.2f} 纳秒")
这样做的好处是：
- 初始化只执行一次，避免重复创建对象带来额外开销；
- 测试代码专注于目标操作，确保测量的是真正关心的部分；
- 支持跨作用域访问变量，通过
globals()或locals()显式传递命名空间。
类似地，如果我们想比较 set 和 list 在成员检查上的性能差异，只需替换 setup 中的数据结构即可：
delay_set = timeit.timeit(
setup="""
numbers = set(range(10000))
probe = 7777
""",
stmt="probe in numbers",
globals=globals(),
number=count,
)
avg_time_set = (delay_set / count) * 1e9
print(f"set 成员查找耗时: {avg_time_set:.2f} 纳秒")
最终我们会发现 set 的查找速度比 list 快几个数量级，这正是哈希表结构的优势所在。
四、如何衡量循环函数的性能并进行归一化？
对于涉及大量循环的函数，如对列表求和：
def loop_sum(items):
total = 0
for i in items:
total += i
return total
我们希望了解每个元素的平均处理时间，而不是整个函数的总耗时。为此，可以先测量函数整体耗时，再根据元素个数进行归一化：
count = 1000
delay = timeit.timeit(
setup="numbers = list(range(10000))",
stmt="loop_sum(numbers)",
globals=globals(),
number=count,
)
avg_time_per_call = (delay / count) * 1e9
avg_time_per_item = avg_time_per_call / 10000
print(f"loop_sum 函数调用耗时: {avg_time_per_call:.2f} 纳秒/次")
print(f"每个元素耗时: {avg_time_per_item:.2f} 纳秒/元素")
输出可能是：
loop_sum 函数调用耗时: 142365.46 纳秒/次
每个元素耗时: 14.43 纳秒/元素
这种归一化处理使我们能够清晰地看到函数随输入规模增长的趋势，便于评估其可扩展性。
总结
通过本文的学习，我们掌握了以下几个关键点：
- 使用
timeit模块进行精准计时：相比简单的time.time()，timeit提供了更稳定、可重复的测量机制。 - 避免低迭代次数带来的误差：至少应运行十万到百万次迭代，并计算平均值以消除系统噪声影响。
- 利用
setup隔离初始化逻辑：确保测试聚焦于目标操作本身，而非整个函数流程。 - 对循环函数进行归一化分析：通过除以元素个数，得到单位操作的平均耗时，有助于评估性能瓶颈。
这些技巧不仅适用于本书提到的 list 与 set 查找对比，还可以广泛应用于各种性能敏感场景，如数据库查询优化、缓存策略设计、算法复杂度验证等。
结语
学习 timeit 的过程让我深刻体会到：性能优化不是玄学，而是可以通过科学方法量化和验证的过程。过去我常常凭直觉选择数据结构或算法，但现在有了 timeit，我可以更有信心地做出决策。
如果你觉得这篇文章对你有所帮助，欢迎点赞、收藏、分享给你的朋友！后续我会继续分享更多关于《Effective Python》精读笔记系列，参考我的代码库 effective_python_3rd，一起交流成长！