为什么使用列表推导的Python函数式代码性能不如过程式循环实现？

• 性能差异不是「函数式范式比过程式范式慢」导致的，问题出在你当前的函数式实现存在多余的性能开销，核心原因有三个：
  1. 多了一倍的全量遍历开销：proc_counter只遍历一次输入列表就同时完成了数字计数和单词数累加，而你的func_counter首先遍历一次列表生成中间列表lst，之后调用collections.Counter统计0的个数时又要遍历一次lst，两次遍历的基础开销本来就比一次遍历高。
  2. 多余的中间对象内存开销：你生成了完整的中间列表lst，需要额外申请内存存储所有元素的计算结果，而proc_counter全程只维护两个整数计数器，没有额外的列表内存分配和读写开销。
  3. 不必要的工具类调用开销：collections.Counter是通用统计类，本身初始化、执行统计逻辑都有固定的调用开销。你只是要统计列表中0的个数，完全不需要用到Counter，哪怕直接用lst.count(0)也比调用Counter开销小，但count依然要遍历一次列表，还是没有解决多次遍历的问题。
• 你的实现逻辑没有正确性问题，只是存在性能优化空间，如果要写高效的函数式版本，可以参考用reduce实现单次遍历的版本，不需要生成中间列表也不需要多次遍历：

from functools import reduce

def func_counter_opt(A):
    wrds, nums = reduce(
        lambda acc, elem: (acc[0] + len(elem.split()), acc[1]) 
        if type(elem) == str 
        else (acc[0], acc[1] + 1), 
        A, 
        (0, 0)
    )
    return "Count of words = {} and Count of numbers = {}".format(wrds,nums)

这个版本的性能和你写的过程式版本基本持平，部分场景下因为reduce是C实现的执行逻辑，性能还会略高于纯Python写的for循环版本。

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