Python中for循环为何比sum+生成器表达式更快？原因探究

这个反直觉的结果其实和Python中生成器表达式的迭代器开销直接相关，咱们一步步拆解原因：

1. 两种实现的底层执行差异 #

先再聚焦下两个函数的核心逻辑：

• facdigits1：用本地变量total做累加，for循环直接遍历map(int, str(n))的结果，每次取出i后直接从数组F取值加到total上，全程在当前函数的作用域内完成操作。
• facdigits2：依赖sum()函数去迭代一个生成器表达式，每次迭代都要通过生成器的__next__()方法取出下一个F[i]值，再传递给sum做累加，相当于多了一层“中间代理”。

2. 生成器的额外开销在哪里？ #

生成器是惰性求值的，虽然它能节省内存（不用一次性生成所有元素的列表），但在这种简单的小数据场景下，内存优势可以忽略，反而额外的运行时开销会凸显：

• 生成器对象的创建与迭代开销：生成器表达式会创建一个专门的生成器对象，每次迭代都要调用其__next__()方法，这比直接在函数本地的for循环多了一层函数调用的开销。
• 本地变量访问的速度优势：facdigits1里的total是函数的本地变量，Python对本地变量的访问用的是LOAD_FAST指令，速度极快；而生成器迭代时，每次取F[i]的操作加上生成器的帧切换，都会带来额外的性能损耗。
• sum函数的额外处理逻辑：sum处理生成器时，需要不断从生成器拉取数据，这个过程比直接在循环里做累加多了一层数据传递的步骤。

3. 补充验证：列表推导式 vs 生成器表达式 #

如果把facdigits2改成用列表推导式：

def facdigits3(n):
    return sum([F[i] for i in map(int, str(n))])

你会发现它的速度会比生成器版本快一些（但还是可能略慢于facdigits1），因为列表推导式是一次性生成所有元素的列表，减少了迭代器的多次调用开销，但依然有列表创建的额外成本，还是比直接循环累加慢一点。

总结 #

虽然生成器表达式和sum()的组合看起来更简洁优雅，但在这种简单、小规模的累加场景下，生成器带来的迭代器开销会超过它的优势，反而不如显式的本地循环累加高效。

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