![](/img/trans.png)
[英]Comparing list comprehensions and explicit loops (3 array generators faster than 1 for loop)
[英]Are list-comprehensions and functional functions faster than "for loops"?
就 Python 的性能而言,列表理解或map()
、 filter()
和reduce()
之類的函數是否比 for 循環更快? 為什么從技術上講,它們以 C 的速度運行,而for 循環以 python 的虛擬機速度運行?。
假設在我正在開發的游戲中,我需要使用 for 循環繪制復雜而巨大的地圖。 這個問題肯定是相關的,因為如果列表理解確實更快,那么為了避免滯后,這將是一個更好的選擇(盡管代碼的視覺復雜性)。
以下是粗略的指導方針和基於經驗的有根據的猜測。 您應該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% 加速比 300% 加速,同樣的努力)。
如果您查看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
找出結果更快。
您專門詢問map()
、 filter()
和reduce()
,但我假設您想了解一般的函數式編程。 在計算一組點中所有點之間的距離的問題上自己對此進行了測試后,函數式編程(使用內置itertools
模塊中的starmap
函數)結果證明比 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')
我寫了一個簡單的腳本來測試速度,這就是我發現的。 實際上 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
我修改了cProfile
的代碼並使用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
使用 append,這當然在某種程度上很慢map
相比,list-comprehension 不僅在構建列表上花費的時間最少,而且使sum
速度更快為Alphii 答案添加一個轉折,實際上 for 循環將是第二好的並且比map
慢約 6 倍
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
我設法修改了@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
我正在尋找有關“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 倍。 有關詳細信息,請參閱更快的 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 倍),但“地圖”的性能改進可以忽略不計。
#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
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.