問(wèn)題

你的程序運(yùn)行太慢，你想在不使用復(fù)雜技術(shù)比如C擴(kuò)展或JIT編譯器的情況下加快程序運(yùn)行速度。

解決方案

關(guān)于程序優(yōu)化的第一個(gè)準(zhǔn)則是“不要優(yōu)化”，第二個(gè)準(zhǔn)則是“不要優(yōu)化那些無(wú)關(guān)緊要的部分”。 如果你的程序運(yùn)行緩慢，首先你得使用14.13小節(jié)的技術(shù)先對(duì)它進(jìn)行性能測(cè)試找到問(wèn)題所在。

通常來(lái)講你會(huì)發(fā)現(xiàn)你得程序在少數(shù)幾個(gè)熱點(diǎn)位置花費(fèi)了大量時(shí)間， 比如內(nèi)存的數(shù)據(jù)處理循環(huán)。一旦你定位到這些點(diǎn)，你就可以使用下面這些實(shí)用技術(shù)來(lái)加速程序運(yùn)行。

使用函數(shù)

很多程序員剛開(kāi)始會(huì)使用Python語(yǔ)言寫(xiě)一些簡(jiǎn)單腳本。 當(dāng)編寫(xiě)腳本的時(shí)候，通常習(xí)慣了寫(xiě)毫無(wú)結(jié)構(gòu)的代碼，比如：

# somescript.pyimport sysimport csvwith open(sys.argv[1]) as f: for row in csv.reader(f): # Some kind of processing pass

很少有人知道，像這樣定義在全局范圍的代碼運(yùn)行起來(lái)要比定義在函數(shù)中運(yùn)行慢的多。 這種速度差異是由于局部變量和全局變量的實(shí)現(xiàn)方式（使用局部變量要更快些）。 因此，如果你想讓程序運(yùn)行更快些，只需要將腳本語(yǔ)句放入函數(shù)中即可：

# somescript.pyimport sysimport csvdef main(filename): with open(filename) as f: for row in csv.reader(f): # Some kind of processing passmain(sys.argv[1])

速度的差異取決于實(shí)際運(yùn)行的程序，不過(guò)根據(jù)經(jīng)驗(yàn)，使用函數(shù)帶來(lái)15-30%的性能提升是很常見(jiàn)的。

盡可能去掉屬性訪問(wèn)

每一次使用點(diǎn)(.)操作符來(lái)訪問(wèn)屬性的時(shí)候會(huì)帶來(lái)額外的開(kāi)銷(xiāo)。 它會(huì)觸發(fā)特定的方法，比如 __getattribute__() 和 __getattr__() ，這些方法會(huì)進(jìn)行字典操作操作。

通常你可以使用 from module import name 這樣的導(dǎo)入形式，以及使用綁定的方法。 假設(shè)你有如下的代碼片段：

import mathdef compute_roots(nums): result = [] for n in nums: result.append(math.sqrt(n)) return result# Testnums = range(1000000)for n in range(100): r = compute_roots(nums)

在我們機(jī)器上面測(cè)試的時(shí)候，這個(gè)程序花費(fèi)了大概40秒。現(xiàn)在我們修改 compute_roots() 函數(shù)如下：

from math import sqrtdef compute_roots(nums): result = [] result_append = result.append for n in nums: result_append(sqrt(n)) return result

修改后的版本運(yùn)行時(shí)間大概是29秒。唯一不同之處就是消除了屬性訪問(wèn)。 用 sqrt() 代替了 math.sqrt() 。 The result.append() 方法被賦給一個(gè)局部變量 result_append ，然后在內(nèi)部循環(huán)中使用它。

不過(guò)，這些改變只有在大量重復(fù)代碼中才有意義，比如循環(huán)。 因此，這些優(yōu)化也只是在某些特定地方才應(yīng)該被使用。

理解局部變量

之前提過(guò)，局部變量會(huì)比全局變量運(yùn)行速度快。 對(duì)于頻繁訪問(wèn)的名稱(chēng)，通過(guò)將這些名稱(chēng)變成局部變量可以加速程序運(yùn)行。 例如，看下之前對(duì)于 compute_roots() 函數(shù)進(jìn)行修改后的版本：

import mathdef compute_roots(nums): sqrt = math.sqrt result = [] result_append = result.append for n in nums: result_append(sqrt(n)) return result

在這個(gè)版本中，sqrt 從 math 模塊被拿出并放入了一個(gè)局部變量中。 如果你運(yùn)行這個(gè)代碼，大概花費(fèi)25秒（對(duì)于之前29秒又是一個(gè)改進(jìn)）。 這個(gè)額外的加速原因是因?yàn)閷?duì)于局部變量 sqrt 的查找要快于全局變量 sqrt

對(duì)于類(lèi)中的屬性訪問(wèn)也同樣適用于這個(gè)原理。 通常來(lái)講，查找某個(gè)值比如 self.name 會(huì)比訪問(wèn)一個(gè)局部變量要慢一些。 在內(nèi)部循環(huán)中，可以將某個(gè)需要頻繁訪問(wèn)的屬性放入到一個(gè)局部變量中。例如：

# Slowerclass SomeClass: ... def method(self): for x in s: op(self.value)# Fasterclass SomeClass: ... def method(self): value = self.value for x in s: op(value)

避免不必要的抽象

任何時(shí)候當(dāng)你使用額外的處理層（比如裝飾器、屬性訪問(wèn)、描述器）去包裝你的代碼時(shí)，都會(huì)讓程序運(yùn)行變慢。 比如看下如下的這個(gè)類(lèi)：

class A: def __init__(self, x, y): self.x = x self.y = y @property def y(self): return self._y @y.setter def y(self, value): self._y = value

現(xiàn)在進(jìn)行一個(gè)簡(jiǎn)單測(cè)試：

>>> from timeit import timeit>>> a = A(1,2)>>> timeit(’a.x’, ’from __main__ import a’)0.07817923510447145>>> timeit(’a.y’, ’from __main__ import a’)0.35766440676525235>>>

可以看到，訪問(wèn)屬性y相比屬性x而言慢的不止一點(diǎn)點(diǎn)，大概慢了4.5倍。 如果你在意性能的話，那么就需要重新審視下對(duì)于y的屬性訪問(wèn)器的定義是否真的有必要了。 如果沒(méi)有必要，就使用簡(jiǎn)單屬性吧。 如果僅僅是因?yàn)槠渌幊陶Z(yǔ)言需要使用getter/setter函數(shù)就去修改代碼風(fēng)格，這個(gè)真的沒(méi)有必要。

使用內(nèi)置的容器

內(nèi)置的數(shù)據(jù)類(lèi)型比如字符串、元組、列表、集合和字典都是使用C來(lái)實(shí)現(xiàn)的，運(yùn)行起來(lái)非常快。 如果你想自己實(shí)現(xiàn)新的數(shù)據(jù)結(jié)構(gòu)（比如鏈接列表、平衡樹(shù)等）， 那么要想在性能上達(dá)到內(nèi)置的速度幾乎不可能，因此，還是乖乖的使用內(nèi)置的吧。

避免創(chuàng)建不必要的數(shù)據(jù)結(jié)構(gòu)或復(fù)制

有時(shí)候程序員想顯擺下，構(gòu)造一些并沒(méi)有必要的數(shù)據(jù)結(jié)構(gòu)。例如，有人可能會(huì)像下面這樣寫(xiě)：

values = [x for x in sequence]squares = [x*x for x in values]

也許這里的想法是首先將一些值收集到一個(gè)列表中，然后使用列表推導(dǎo)來(lái)執(zhí)行操作。 不過(guò)，第一個(gè)列表完全沒(méi)有必要，可以簡(jiǎn)單的像下面這樣寫(xiě)：

squares = [x*x for x in sequence]

與此相關(guān)，還要注意下那些對(duì)Python的共享數(shù)據(jù)機(jī)制過(guò)于偏執(zhí)的程序所寫(xiě)的代碼。 有些人并沒(méi)有很好的理解或信任Python的內(nèi)存模型，濫用 copy.deepcopy() 之類(lèi)的函數(shù)。 通常在這些代碼中是可以去掉復(fù)制操作的。

討論

在優(yōu)化之前，有必要先研究下使用的算法。 選擇一個(gè)復(fù)雜度為 O(n log n) 的算法要比你去調(diào)整一個(gè)復(fù)雜度為 O(n**2) 的算法所帶來(lái)的性能提升要大得多。

如果你覺(jué)得你還是得進(jìn)行優(yōu)化，那么請(qǐng)從整體考慮。 作為一般準(zhǔn)則，不要對(duì)程序的每一個(gè)部分都去優(yōu)化,因?yàn)檫@些修改會(huì)導(dǎo)致代碼難以閱讀和理解。 你應(yīng)該專(zhuān)注于優(yōu)化產(chǎn)生性能瓶頸的地方，比如內(nèi)部循環(huán)。

你還要注意微小優(yōu)化的結(jié)果。例如考慮下面創(chuàng)建一個(gè)字典的兩種方式：

a = { ’name’ : ’AAPL’, ’shares’ : 100, ’price’ : 534.22}b = dict(name=’AAPL’, shares=100, price=534.22)

后面一種寫(xiě)法更簡(jiǎn)潔一些（你不需要在關(guān)鍵字上輸入引號(hào)）。 不過(guò)，如果你將這兩個(gè)代碼片段進(jìn)行性能測(cè)試對(duì)比時(shí)，會(huì)發(fā)現(xiàn)使用 dict() 的方式會(huì)慢了3倍。 看到這個(gè)，你是不是有沖動(dòng)把所有使用 dict() 的代碼都替換成第一種。 不夠，聰明的程序員只會(huì)關(guān)注他應(yīng)該關(guān)注的地方，比如內(nèi)部循環(huán)。在其他地方，這點(diǎn)性能損失沒(méi)有什么影響。

如果你的優(yōu)化要求比較高，本節(jié)的這些簡(jiǎn)單技術(shù)滿(mǎn)足不了，那么你可以研究下基于即時(shí)編譯（JIT）技術(shù)的一些工具。 例如，PyPy工程是Python解釋器的另外一種實(shí)現(xiàn)，它會(huì)分析你的程序運(yùn)行并對(duì)那些頻繁執(zhí)行的部分生成本機(jī)機(jī)器碼。 它有時(shí)候能極大的提升性能，通常可以接近C代碼的速度。 不過(guò)可惜的是，到寫(xiě)這本書(shū)為止，PyPy還不能完全支持Python3. 因此，這個(gè)是你將來(lái)需要去研究的。你還可以考慮下Numba工程， Numba是一個(gè)在你使用裝飾器來(lái)選擇Python函數(shù)進(jìn)行優(yōu)化時(shí)的動(dòng)態(tài)編譯器。 這些函數(shù)會(huì)使用LLVM被編譯成本地機(jī)器碼。它同樣可以極大的提升性能。 但是，跟PyPy一樣，它對(duì)于Python 3的支持現(xiàn)在還停留在實(shí)驗(yàn)階段。

最后我引用John Ousterhout說(shuō)過(guò)的話作為結(jié)尾：“最好的性能優(yōu)化是從不工作到工作狀態(tài)的遷移”。 直到你真的需要優(yōu)化的時(shí)候再去考慮它。確保你程序正確的運(yùn)行通常比讓它運(yùn)行更快要更重要一些（至少開(kāi)始是這樣的）.

以上就是Python加速程序運(yùn)行的方法的詳細(xì)內(nèi)容，更多關(guān)于Python加速程序運(yùn)行的資料請(qǐng)關(guān)注好吧啦網(wǎng)其它相關(guān)文章！