timeit.Timer中stmt与functools.partial的性能对比及适用场景

已知functools.partial(fn, *args, **kw)相比lambda: fn(*args, **kw)能节省开销，但它相比stmt+globals的组合是否同样具有优势？

以下是三种timeit.Timer的使用方式：

1. timeit.Timer(partial(fn, *args, **kw)).repeat(200, 5)
2. timeit.Timer(stmt='fn(*args, **kw)', globals={'fn': fn, 'args': args, 'kw': kw})
3. timeit.Timer(stmt='fn(*args, **kw)', globals={'args': args, 'kw': kw}, setup='from __main__ import fn')

需要明确以下问题：

• 当fn的执行时长达到何种量级（如毫秒级）时，三者的差异会不可忽略？
• 当时长超过某一量级后，包括在并行（非Python多进程，如numpy多核运算）及GPU基准测试场景下，三者是否可互换使用？
• 除命令行方式外，哪一种是更通用的首选方案？

附使用场景：存在耗时的setup函数，在main函数中针对多种配置进行基准测试，测试对象非x += 1这类微基准测试，而是毫秒级耗时的任务。已在不同CPU上测试partial与长格式写法的耗时差异。

核心结论与分析 #

1. 差异不可忽略的时长量级 #

三者的性能差异本质是**调用额外开销（overhead）**的差别：

• partial是预绑定参数的可调用对象，调用时的额外开销极小，接近直接调用fn(*args, **kw)；
• 写法2和3的stmt字符串需要timeit每次解析执行，额外开销比partial略高，但这个差值通常在纳秒到微秒级。

只有当fn的执行时长远小于1毫秒（比如微秒级）时，这种overhead的占比才会被放大，三者的差异才会不可忽略。如果是你场景中的毫秒级任务，overhead占比最多只有千分之一甚至更低，完全可以忽略不计。

2. 超量级后（并行/GPU场景）是否可互换 #

当fn的执行时长达到几十毫秒及以上时，三种写法的overhead占比会低到可以忽略，此时三者完全可以互换使用——不管是numpy多核运算还是GPU计算，核心耗时都在任务本身，timeit的调用方式带来的差异几乎测不出来。

需要注意：如果你的GPU任务是通过CUDA等异步API提交的，要确保timeit能准确捕获实际执行时间（比如同步GPU操作），但这和三种写法的选择无关，是基准测试的通用注意事项。

3. 通用首选方案 #

优先选写法2，理由如下：

• 写法1的partial虽然开销略小，但如果args或kw是可变对象（比如列表、字典），预绑定后可能会意外修改原对象，埋下bug；
• 写法3通过setup导入fn，如果测试代码不在__main__模块（比如封装在函数或类里），会出现找不到fn的问题，兼容性差；
• 写法2直接把fn、args、kw传入globals，既避免了可变对象的问题，又不依赖模块结构，通用性最强，同时性能损失可以忽略（尤其是你的毫秒级任务场景）。

如果是极端的微基准测试（微秒级任务），可以考虑写法1，但要注意可变对象的陷阱；其他场景一律优先写法2。

内容的提问来源于stack exchange，提问作者OverLordGoldDragon