最佳化Python代碼使其加快範圍內的尋找

我將示範微最佳化（micro optimization）如何提升python代碼5%的執行速度。5%！同時也會觸怒任何維護你代碼的人。

但實際上，這篇文章只是解釋一下你偶爾會在標準庫或者其他人的代碼中碰到的代碼。我們先看一個標準庫的例子，collections.OrderedDict類：

def __setitem__(self, key, value, dict_setitem=dict.__setitem__): if key not in self:  root = self.__root  last = root[0]  last[1] = root[0] = self.__map[key] = [last, root, key] return dict_setitem(self, key, value)

注意最後一個參數：dict_setitem=dict.__setitem__。如果你仔細想就會感覺有道理。將值關聯到鍵上，你只需要給__setitem__傳遞三個參數：要設定的鍵，與鍵關聯的值，傳遞給內建dict類的__setitem__類方法。等會，好吧，也許最後一個參數沒什麼意義。
範圍查詢

為了理解到底發生了什麼，我們看下範圍。從一個簡單問題開始：在一個python函數中，如果遇到了一個名為open的東西，python如何找出open的值？

#  def myfunc(): #  with open('foo.txt', 'w') as f:  pass

簡單作答：如果不知道GLOBAL和LOCAL的內容，你不可能確定open的值。概念上，python尋找名稱時會檢查3個命名空間（簡單起見忽略嵌套範圍）：

局部命名空間
全域命名空間
內建命名空間

所以在myfunc函數中，如果嘗試尋找open的值時，我們首先會檢查本地命名空間，然後是全域命名空間，接著內建命名空間。如果在這3個命名空間中都找不到open的定義，就會引發NameError異常。
範圍尋找的實現

上面的尋找過程只是概念上的。這個尋找過程的實現給予了我們探索實現的空間。

def foo(): a = 1 return a def bar(): return a def baz(a=1): return a

我們看下每個函數的位元組碼：

>>> import dis>>> dis.dis(foo) 2   0 LOAD_CONST    1 (1)    3 STORE_FAST    0 (a)  3   6 LOAD_FAST    0 (a)    9 RETURN_VALUE >>> dis.dis(bar) 2   0 LOAD_GLOBAL    0 (a)    3 RETURN_VALUE >>> dis.dis(baz) 2   0 LOAD_FAST    0 (a)    3 RETURN_VALUE

注意foo和bar的區別。我們立即就可以看到，在位元組碼層面，python已經判斷了什麼是局部變數、什麼不是，因為foo使用LOAD_FAST，而bar使用LOAD_GLOBAL。

我們不會具體闡述python的編譯器如何知道何時產生何種位元組碼（也許那是另一篇文章的範疇了），但足以理解，python在執行函數時已經知道進行何種類型的尋找。

另一個容易混淆的是，LOAD_GLOBAL既可以用於全域，也可以用於內建命名空間的尋找。忽略嵌套範圍的問題，你可以認為這是“非局部的”。對應的C代碼大概是[1]：

case LOAD_GLOBAL: v = PyObject_GetItem(f->f_globals, name); if (v == NULL) {  v = PyObject_GetItem(f->f_builtins, name);  if (v == NULL) {   if (PyErr_ExceptionMatches(PyExc_KeyError))    format_exc_check_arg(       PyExc_NameError,       NAME_ERROR_MSG, name);   goto error;  } } PUSH(v);

即使你從來沒有看過CPython的C代碼，上面的代碼已經相當直白了。首先，檢查我們尋找的鍵名是否在f->f_globals（全域字典）中，然後檢查名稱是否在f->f_builtins（內建字典）中，最後，如果上面兩個位置都沒找到，就會拋出NameError異常。
將常量綁定到局部範圍

現在我們再看最開始的代碼例子，就會理解最後一個參數其實是將一個函數綁定到局部範圍中的一個函數上。具體是通過將dict.__setitem__賦值為參數的預設值。這裡還有另一個例子：

def not_list_or_dict(value): return not (isinstance(value, dict) or isinstance(value, list)) def not_list_or_dict(value, _isinstance=isinstance, _dict=dict, _list=list): return not (_isinstance(value, _dict) or _isinstance(value, _list))

這裡我們做同樣的事情，把本來將會在內建命名空間中的對象綁定到局部範圍中去。因此，python將會使用LOCAL_FAST而不是LOAD_GLOBAL（全域尋找）。那麼這到底有多快呢？我們做個簡單的測試：

$ python -m timeit -s 'def not_list_or_dict(value): return not (isinstance(value, dict) or isinstance(value, list))' 'not_list_or_dict(50)'1000000 loops, best of 3: 0.48 usec per loop$ python -m timeit -s 'def not_list_or_dict(value, _isinstance=isinstance, _dict=dict, _list=list): return not (_isinstance(value, _dict) or _isinstance(value, _list))' 'not_list_or_dict(50)'1000000 loops, best of 3: 0.423 usec per loop

換句話說，大概有11.9%的提升 [2]。比我在文章開始處承諾的5%還多！
還有更多內涵

可以合理地認為，速度提升在於LOAD_FAST讀取局部範圍，而LOAD_GLOBAL在檢查內建範圍之前會先首先檢查全域範圍。上面那個樣本函數中，isinstance、dict、list都位於內建命名空間。

但是，還有更多。我們不僅可以使用LOAD_FAST跳過多餘的尋找，它也是一種不同類型的尋找。

上面C程式碼片段給出了LOAD_GLOBAL的代碼，下面是LOAD_FAST的：

case LOAD_FAST: PyObject *value = fastlocal[oparg]; if (value == NULL) {  format_exc_check_arg(PyExc_UnboundLocalError,        UNBOUNDLOCAL_ERROR_MSG,        PyTuple_GetItem(co->co_varnames, oparg));  goto error; } Py_INCREF(value); PUSH(value); FAST_DISPATCH()

我們通過索引一個數組擷取局部值。雖然沒有直接出現，但是oparg只是那個數組的一個索引。

現在聽起來才合理。我們第一個版本的not_list_or_dict要進行4個查詢，每個名稱都位於內建命名空間，它們只有在尋找全域命名空間之後才會查詢。這就是8個字典鍵的查詢操作了。相比之下，not_list_or_dict的第二版中，直接索引C數組4次，底層全部使用LOAD_FAST。這就是為什麼局部查詢更快的原因。
總結

現在當下次你在其他人代碼中看到這種例子，就會明白了。

最後，除非確實需要，請不要在具體應用中進行這類最佳化。而且大部分時間你都沒必要做。但是如果時候到了，你需要擠出最後一點效能，就需要搞懂這點。
腳註

[1]注意，為了更易讀，上面的代碼中我去掉了一些效能最佳化。真正的代碼稍微有點複雜。

[2]樣本函數事實上沒有做什麼有價值的東西，也沒進行IO操作，大部分是受python VM迴圈的限制。

