列表推导和功能函数是否比“for循环”更快？
- 2024-12-04 08:56:00
- admin 原创
- 146
问题描述：
就 Python 的性能而言，列表推导式或类似 的函数是否map()比filter()forreduce()循环更快？为什么从技术上讲，它们以 C 速度运行，而for 循环以 python 虚拟机速度运行？
假设在我开发的游戏中，我需要使用 for 循环绘制复杂且巨大的地图。这个问题肯定是相关的，因为如果列表推导确实更快，那么它将是一个更好的选择，以避免延迟（尽管代码的视觉复杂性）。
解决方案 1：
以下是基于经验的粗略指导和有根据的猜测。您应该timeit分析您的具体用例以获取确切数字，这些数字有时可能与以下内容不一致。
列表推导通常比精确等效的循环（实际构建列表）稍快一点for，很可能是因为它不必append在每次迭代时查找列表及其方法。但是，列表推导仍然执行字节码级循环：
>>> dis.dis(<the code object for `[x for x in range(10)]`>)
1 0 BUILD_LIST 0
3 LOAD_FAST 0 (.0)
>> 6 FOR_ITER 12 (to 21)
9 STORE_FAST 1 (x)
12 LOAD_FAST 1 (x)
15 LIST_APPEND 2
18 JUMP_ABSOLUTE 6
>> 21 RETURN_VALUE
使用列表推导式代替不构建列表的循环，无意义地积累无意义的值列表，然后丢弃列表，通常会因为创建和扩展列表的开销而变慢。列表推导式并不是天生就比传统循环更快的魔法。
至于函数列表处理函数：虽然这些函数是用 C 编写的，并且可能比用 Python 编写的等效函数性能更好，但它们不一定是最快的选择。如果函数也是用 C 编写的，则速度会有所提高。但大多数情况下使用lambda（或其他 Python 函数），重复设置 Python 堆栈框架等的开销会消耗掉任何节省。只需在线执行相同的工作，而无需函数调用（例如，使用列表理解而不是map或filter）通常会稍微快一些。
假设在我开发的游戏中，我需要使用 for 循环绘制复杂且巨大的地图。这个问题肯定是相关的，因为如果列表推导确实更快，那么它将是一个更好的选择，以避免延迟（尽管代码的视觉复杂性）。
很有可能，如果这样的代码在用良好的非“优化” Python 编写时速度不够快，那么无论多少 Python 级别的微优化都无法使其足够快，您应该开始考虑使用 C。虽然广泛的微优化通常可以大大加快 Python 代码的速度，但这样做有一个低限（绝对值）。此外，即使在您达到这个上限之前，咬紧牙关编写一些 C 代码也会变得更具成本效益（15% 的加速 vs. 同样的努力可以达到 300% 的加速）。
解决方案 2：
如果你查看python.org 上的信息，你会看到以下摘要：
Version Time (seconds)
Basic loop 3.47
Eliminate dots 2.45
Local variable & no dots 1.79
Using map function 0.54
但您确实应该详细阅读上述文章以了解性能差异的原因。
我还强烈建议您使用timeit来计时代码。最终，可能会出现这样的情况，例如，for当满足条件时，您可能需要跳出循环。这可能比通过调用 来找出结果更快map。
解决方案 3：
我修改了@Alisa 的代码并用来cProfile展示为什么列表理解更快：
from functools import reduce
import datetime
def reduce_(numbers):
return reduce(lambda sum, next: sum + next * next, numbers, 0)
def for_loop(numbers):
a = []
for i in numbers:
a.append(i*2)
a = sum(a)
return a
def map_(numbers):
sqrt = lambda x: x*x
return sum(map(sqrt, numbers))
def list_comp(numbers):
return(sum([i*i for i in numbers]))
funcs = [
reduce_,
for_loop,
map_,
list_comp
]
if __name__ == "__main__":
# [1, 2, 5, 3, 1, 2, 5, 3]
import cProfile
for f in funcs:
print('=' * 25)
print("Profiling:", f.__name__)
print('=' * 25)
pr = cProfile.Profile()
for i in range(10**6):
pr.runcall(f, [1, 2, 5, 3, 1, 2, 5, 3])
pr.create_stats()
pr.print_stats()
结果如下：
=========================
Profiling: reduce_
=========================
11000000 function calls in 1.501 seconds
Ordered by: standard name
ncalls tottime percall cumtime percall filename:lineno(function)
1000000 0.162 0.000 1.473 0.000 profiling.py:4(reduce_)
8000000 0.461 0.000 0.461 0.000 profiling.py:5(<lambda>)
1000000 0.850 0.000 1.311 0.000 {built-in method _functools.reduce}
1000000 0.028 0.000 0.028 0.000 {method 'disable' of '_lsprof.Profiler' objects}
=========================
Profiling: for_loop
=========================
11000000 function calls in 1.372 seconds
Ordered by: standard name
ncalls tottime percall cumtime percall filename:lineno(function)
1000000 0.879 0.000 1.344 0.000 profiling.py:7(for_loop)
1000000 0.145 0.000 0.145 0.000 {built-in method builtins.sum}
8000000 0.320 0.000 0.320 0.000 {method 'append' of 'list' objects}
1000000 0.027 0.000 0.027 0.000 {method 'disable' of '_lsprof.Profiler' objects}
=========================
Profiling: map_
=========================
11000000 function calls in 1.470 seconds
Ordered by: standard name
ncalls tottime percall cumtime percall filename:lineno(function)
1000000 0.264 0.000 1.442 0.000 profiling.py:14(map_)
8000000 0.387 0.000 0.387 0.000 profiling.py:15(<lambda>)
1000000 0.791 0.000 1.178 0.000 {built-in method builtins.sum}
1000000 0.028 0.000 0.028 0.000 {method 'disable' of '_lsprof.Profiler' objects}
=========================
Profiling: list_comp
=========================
4000000 function calls in 0.737 seconds
Ordered by: standard name
ncalls tottime percall cumtime percall filename:lineno(function)
1000000 0.318 0.000 0.709 0.000 profiling.py:18(list_comp)
1000000 0.261 0.000 0.261 0.000 profiling.py:19(<listcomp>)
1000000 0.131 0.000 0.131 0.000 {built-in method builtins.sum}
1000000 0.027 0.000 0.027 0.000 {method 'disable' of '_lsprof.Profiler' objects}
恕我直言：
reduce并且map通常相当慢。不仅如此，与使用列表相比，使用返回sum的迭代器也很慢map`sum`for_loop使用附加，这当然在某种程度上是缓慢的列表推导式不仅花费最少的时间来构建列表，而且
sum与map
解决方案 4：
您具体询问的是map()和filter()，reduce()但我假设您想了解函数式编程的一般知识。我自己在计算一组点内所有点之间的距离问题上进行了测试，结果发现函数式编程（使用starmap内置模块中的函数itertools）比 for 循环稍慢（实际上花费 1.25 倍的时间）。这是我使用的示例代码：
import itertools, time, math, random
class Point:
def __init__(self,x,y):
self.x, self.y = x, y
point_set = (Point(0, 0), Point(0, 1), Point(0, 2), Point(0, 3))
n_points = 100
pick_val = lambda : 10 * random.random() - 5
large_set = [Point(pick_val(), pick_val()) for _ in range(n_points)]
# the distance function
f_dist = lambda x0, x1, y0, y1: math.sqrt((x0 - x1) ** 2 + (y0 - y1) ** 2)
# go through each point, get its distance from all remaining points
f_pos = lambda p1, p2: (p1.x, p2.x, p1.y, p2.y)
extract_dists = lambda x: itertools.starmap(f_dist,
itertools.starmap(f_pos,
itertools.combinations(x, 2)))
print('Distances:', list(extract_dists(point_set)))
t0_f = time.time()
list(extract_dists(large_set))
dt_f = time.time() - t0_f
函数版本比程序版本更快吗？
def extract_dists_procedural(pts):
n_pts = len(pts)
l = []
for k_p1 in range(n_pts - 1):
for k_p2 in range(k_p1, n_pts):
l.append((pts[k_p1].x - pts[k_p2].x) ** 2 +
(pts[k_p1].y - pts[k_p2].y) ** 2)
return l
t0_p = time.time()
list(extract_dists_procedural(large_set))
# using list() on the assumption that
# it eats up as much time as in the functional version
dt_p = time.time() - t0_p
f_vs_p = dt_p / dt_f
if f_vs_p >= 1.0:
print('Time benefit of functional progamming:', f_vs_p,
'times as fast for', n_points, 'points')
else:
print('Time penalty of functional programming:', 1 / f_vs_p,
'times as slow for', n_points, 'points')
解决方案 5：
我写了一个简单的脚本来测试速度，结果如下。实际上，for 循环对我来说是最快的。这真的让我很惊讶，请查看下文（计算平方和）。
from functools import reduce
import datetime
def time_it(func, numbers, *args):
start_t = datetime.datetime.now()
for i in range(numbers):
func(args[0])
print (datetime.datetime.now()-start_t)
def square_sum1(numbers):
return reduce(lambda sum, next: sum+next**2, numbers, 0)
def square_sum2(numbers):
a = 0
for i in numbers:
i = i**2
a += i
return a
def square_sum3(numbers):
sqrt = lambda x: x**2
return sum(map(sqrt, numbers))
def square_sum4(numbers):
return(sum([int(i)**2 for i in numbers]))
time_it(square_sum1, 100000, [1, 2, 5, 3, 1, 2, 5, 3])
time_it(square_sum2, 100000, [1, 2, 5, 3, 1, 2, 5, 3])
time_it(square_sum3, 100000, [1, 2, 5, 3, 1, 2, 5, 3])
time_it(square_sum4, 100000, [1, 2, 5, 3, 1, 2, 5, 3])
0:00:00.302000 #Reduce
0:00:00.144000 #For loop
0:00:00.318000 #Map
0:00:00.390000 #List comprehension
解决方案 6：
我设法修改了@alpiii 的一些代码，发现列表推导比 for 循环快一点。这可能是由于int()列表推导和 for 循环之间不公平造成的。
from functools import reduce
import datetime
def time_it(func, numbers, *args):
start_t = datetime.datetime.now()
for i in range(numbers):
func(args[0])
print (datetime.datetime.now()-start_t)
def square_sum1(numbers):
return reduce(lambda sum, next: sum+next*next, numbers, 0)
def square_sum2(numbers):
a = []
for i in numbers:
a.append(i*2)
a = sum(a)
return a
def square_sum3(numbers):
sqrt = lambda x: x*x
return sum(map(sqrt, numbers))
def square_sum4(numbers):
return(sum([i*i for i in numbers]))
time_it(square_sum1, 100000, [1, 2, 5, 3, 1, 2, 5, 3])
time_it(square_sum2, 100000, [1, 2, 5, 3, 1, 2, 5, 3])
time_it(square_sum3, 100000, [1, 2, 5, 3, 1, 2, 5, 3])
time_it(square_sum4, 100000, [1, 2, 5, 3, 1, 2, 5, 3])
0:00:00.101122 #Reduce
0:00:00.089216 #For loop
0:00:00.101532 #Map
0:00:00.068916 #List comprehension
解决方案 7：
对Alphii 的答案进行一些修改，实际上 for 循环是第二好的，比map
from functools import reduce
import datetime
def time_it(func, numbers, *args):
start_t = datetime.datetime.now()
for i in range(numbers):
func(args[0])
print (datetime.datetime.now()-start_t)
def square_sum1(numbers):
return reduce(lambda sum, next: sum+next**2, numbers, 0)
def square_sum2(numbers):
a = 0
for i in numbers:
a += i**2
return a
def square_sum3(numbers):
a = 0
map(lambda x: a+x**2, numbers)
return a
def square_sum4(numbers):
a = 0
return [a+i**2 for i in numbers]
time_it(square_sum1, 100000, [1, 2, 5, 3, 1, 2, 5, 3])
time_it(square_sum2, 100000, [1, 2, 5, 3, 1, 2, 5, 3])
time_it(square_sum3, 100000, [1, 2, 5, 3, 1, 2, 5, 3])
time_it(square_sum4, 100000, [1, 2, 5, 3, 1, 2, 5, 3])
主要的变化是消除了缓慢的sum调用，以及int()最后一种情况下可能不必要的调用。实际上，将 for 循环和 map 放在相同的术语中使它成为事实。请记住，lambda 是函数概念，理论上不应该有副作用，但是，它们可能会有副作用，例如添加到a。本例中的结果使用 Python 3.6.1、Ubuntu 14.04、Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
0:00:00.257703 #Reduce
0:00:00.184898 #For loop
0:00:00.031718 #Map
0:00:00.212699 #List comprehension
解决方案 8：
我正在寻找有关“for”循环和“列表推导”的一些性能信息，偶然发现了这个主题。自 Python 3.11 发布（2022 年 10 月）以来已经过去了几个月，Python 3.11 的主要功能之一是速度改进。https:
//www.python.org/downloads/release/python-3110/
Faster CPython 项目已经取得了一些令人兴奋的成果。Python 3.11 比 Python 3.10 快 10-60%。平均而言，我们在标准基准测试套件上测得了 1.22 倍的加速。有关详细信息，请参阅 Faster CPython。
我运行了 Alphi 最初发布的、然后由 jjmerelo “扭曲”的相同代码。Python3.10 和 Python3.11 结果如下：
from functools import reduce
import datetime
def time_it(func, numbers, *args):
start_t = datetime.datetime.now()
for i in range(numbers):
func(args[0])
print(datetime.datetime.now()-start_t)
def square_sum1(numbers):
return reduce(lambda sum, next: sum+next**2, numbers, 0)
def square_sum2(numbers):
a = 0
for i in numbers:
a += i**2
return a
def square_sum3(numbers):
a = 0
map(lambda x: a+x**2, numbers)
return a
def square_sum4(numbers):
a = 0
return [a+i**2 for i in numbers]
time_it(square_sum1, 100000, [1, 2, 5, 3, 1, 2, 5, 3])
time_it(square_sum2, 100000, [1, 2, 5, 3, 1, 2, 5, 3])
time_it(square_sum3, 100000, [1, 2, 5, 3, 1, 2, 5, 3])
time_it(square_sum4, 100000, [1, 2, 5, 3, 1, 2, 5, 3])
我没有计算出确切的百分比提升，但很明显，性能提升 - 至少在这个特定的例子中 - 似乎令人印象深刻（快 3 到 4 倍），但“map”除外，其性能提升可以忽略不计。
#Python 3.10
0:00:00.221134 #Reduce
0:00:00.186307 #For
0:00:00.024311 #Map
0:00:00.206454 #List comprehension
#python3.11
0:00:00.072550 #Reduce
0:00:00.037168 #For
0:00:00.021702 #Map
0:00:00.058655 #List Comprehension
注意：我使用 WSL 在 Windows 11 下运行的 Kali Linux VM 上运行了此代码。我不确定如果在 Linux 实例上本机（裸机）运行此代码是否会表现得更好。
我的 Kali Linux VM 规格如下：
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 39 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Vendor ID: GenuineIntel
Model name: Intel(R) Core(TM) i7-6700T CPU @ 2.80GHz
CPU family: 6
Model: 94
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
Stepping: 3
BogoMIPS: 5615.99
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi ept vpid ept_ad fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves flush_l1d arch_capabilities
Virtualization: VT-x
Hypervisor vendor: Microsoft
Virtualization type: full
L1d cache: 128 KiB (4 instances)
L1i cache: 128 KiB (4 instances)
L2 cache: 1 MiB (4 instances)
L3 cache: 8 MiB (1 instance)
Vulnerability Itlb multihit: KVM: Mitigation: VMX disabled
Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable
Vulnerability Mds: Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown
Vulnerability Meltdown: Mitigation; PTI
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Full generic retpoline, IBPB conditional, IBRS_FW, STIBP conditional, RSB filling
Vulnerability Srbds: Unknown: Dependent on hypervisor status
Vulnerability Tsx async abort: Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown
解决方案 9：
map`map与 一起使用时，比列表推导式要慢lambda。例如，有一个整数列表，您想从第一个列表中获取一个字符串列表：[1, 2, 3] -> ['1', '2', '3']。在这种特殊情况下，您可以避免lambda并写入list(map(str, [1, 2, 3]))`，并且此表达式将比类似的列表推导式更快。
但是，当你需要对输入 Iterable 的每个元素应用超过 1 个参数的函数时（例如，pow需要 2 个参数的内置函数），你无法避免lambda语法问题，并且在这种特殊情况下，类似的列表理解会更快。
相关推荐
热门文章
项目管理软件有哪些？
热门标签
云禅道AD
