摘要:毫無疑問是全局,但是是什么鬼似乎應該叫吧然而事實就是這么神奇,人家就真的是叫,因為局部變量是從一個叫的數組里面讀,故名字也這樣取了。所以我們在一些會頻繁操作類實例屬性的情況下,應該是先把屬性取出來存到局部變量,然后用局部變量來完成操作。
前言
這兩天在 CodeReview 時,看到這樣的代碼
# 偽代碼 import somelib class A(object): def load_project(self): self.project_code_to_name = {} for project in somelib.get_all_projects(): self.project_code_to_name[project] = project ...
意圖很簡單,就是將 somelib.get_all_projects 獲取的項目塞入的 self.project_code_to_name
然而印象中這個是有優化空間的,于是提出調整方案:
import somelib class A(object): def load_project(self): project_code_to_name = {} for project in somelib.get_all_projects(): project_code_to_name[project] = project self.project_code_to_name = project_code_to_name ...
方案很簡單,就是先定義局部變量 project_code_to_name,操作完,再賦值到self.project_code_to_name。
在后面的測試,也確實發現這樣是會好點,那么結果知道了,接下來肯定是想探索原因的!
局部變量其實在網上很多地方,甚至很多書上都有講過一個觀點:訪問局部變量速度要快很多,粗看好像好有道理,然后又看到下面貼了一大堆測試數據,雖然不知道是什么,但這是真的屌,記住再說,管他呢!
但是實際上這個觀點還是有一定的局限性,并不是放諸四海皆準。所以先來理解下這句話吧,為什么大家都喜歡這樣說。
先看段代碼理解下什么是局部變量:
#coding: utf8 a = 1 def test(b): c = "test" print a # 全局變量 print b # 局部變量 print c # 局部變量 test(3)
# 輸出 1 3 test
簡單來說,局部變量就是只作用于所在的函數域,超過作用域就被回收
理解了什么是局部變量,就需要談談 Python 函數 和 局部變量 的愛恨情仇,因為如果不搞清楚這個,是很難感受到到底快在哪里;
為避免枯燥,以上述的代碼來闡述吧,順便附上 test 函數執行 的 dis 的解析:
# CALL_FUNCTION 5 0 LOAD_CONST 1 ("test") 3 STORE_FAST 1 (c) 6 6 LOAD_GLOBAL 0 (a) 9 PRINT_ITEM 10 PRINT_NEWLINE 7 11 LOAD_FAST 0 (b) 14 PRINT_ITEM 15 PRINT_NEWLINE 8 16 LOAD_FAST 1 (c) 19 PRINT_ITEM 20 PRINT_NEWLINE 21 LOAD_CONST 0 (None) 24 RETURN_VALUE
在上圖中比較清楚能看到 a、b、c 分別對應的指令塊,每一塊的第一行都是 LOAD_XXX,顧名思義,是說明這些變量是從哪個地方獲取的。
LOAD_GLOBAL 毫無疑問是全局,但是 LOAD_FAST 是什么鬼?似乎應該叫LOAD_LOCAL 吧?
然而事實就是這么神奇,人家就真的是叫 LOAD_FAST,因為局部變量是從一個叫 fastlocals 的數組里面讀,故名字也這樣取了。
那么是否存在這樣的一個 LOAD_LOCAL?
答案是有的,不過人家不叫這個,而是叫LOAD_LOCALS,而且這個指令在這里卻是完全不同的含義,為何?
因為這個指令幾乎不會在函數運行出現,而是在類定義時才會出現(若其他同學發現其他場景也能看到這個,求分享):
# 測試代碼 class A(object): s = 3
# 字節碼
2 0 LOAD_CONST 0 ("A")
3 LOAD_NAME 0 (object)
6 BUILD_TUPLE 1
9 LOAD_CONST 1 ()
12 MAKE_FUNCTION 0
15 CALL_FUNCTION 0
18 BUILD_CLASS
19 STORE_NAME 1 (A)
22 LOAD_CONST 2 (None)
25 RETURN_VALUE
-------------------- 上面 CALL_FUNCTION 執行的內容如下 -------
2 0 LOAD_NAME 0 (__name__)
3 STORE_NAME 1 (__module__)
3 6 LOAD_CONST 0 (3)
9 STORE_NAME 2 (s)
12 LOAD_LOCALS
13 RETURN_VALUE
這里的 LOAD_NAME 和 STORE_NAME 打了一套組合拳,把 值 和 符號 關聯了起來,并存到 f->f_locals
那么問題來了:f->f_locals是什么?怎么存?
這里的 f 就是一個幀對象,而 f_locals 是它的一個屬性。而這個屬性又比較神奇,在幀對象創建時,會被置為字典,而在函數機制內,又會被置為 NULL, 因為在函數機制內,就會用上面那套 fastlocals了。
那么在這里,就會引出一個小問題,有個叫 locals() 的函數,來打印局部變量,這又是怎么回事? 在另一篇文章已經談到,歡迎移步: https://segmentfault.com/a/11...
接回上文,既然f->f_locals是字典,那就按照我們理解的字典那樣存就好了唄~
這樣就到了久違的LOAD_LOCALS了,具體實現:
TARGET_NOARG(LOAD_LOCALS) { if ((x = f->f_locals) != NULL) { Py_INCREF(x); PUSH(x); DISPATCH(); } PyErr_SetString(PyExc_SystemError, "no locals"); break; }
很通俗易懂,就是把剛才提到的、存了好多符號的 字典,拿出來塞到這個運行時棧 (下文會介紹到這個) 。
塞這個有啥用呢?這煞費苦心的一切,都是為了別人好啊!這種種的一切,都是為了 BUILD_CLASS 準備,因為需要利用這些來創建類!
那么關于類的知識,暫告一段落,下回再分解,咱們跑題都快跑出九霄凌外了
那么主角來了,我們要重點理解這個,因為這個確實還挺有意思。
Python 函數執行Python 函數的構建和運行,說復雜不復雜,說簡單也不簡單,因為它需要區分很多情況,比方說需要區分 函數 和 方法,再而區分是有無參數,有什么參數,有木有變長參數,有木有關鍵參數。
全部展開仔細講是不可能的啦,不過可以簡單圖解下大致的流程(忽略參數變化細節):
一路順流而下,直達 fast_function,它在這里的調用是:
// ceval.c -> call_function x = fast_function(func, pp_stack, n, na, nk);
參數解釋下:
func: 傳入的 test;
pp_stack: 近似理解調用棧 (py方式);
na: 位置參數個數;
nk: 關鍵字個數;
n = na + 2 * nk;
那么下一步就看看 fast_function 要做什么吧。
初始化一波
定義 co 來存放 test 對象里面的 func_code
定義 globals 來存放 test 對象里面的 func_globals (字典)
定義 argdefs 來存放 test 對象里面的 func_defaults (構建函數時的關鍵字參數默認值)
來個判斷,如果 argdefs 為空 && 傳入的位置參數個數 == 函數定義時候的位置形參個數 && 沒有傳入關鍵字參數
那就
用 當前線程狀態、co 、globals 來新建棧對象 f;
定義fastlocals ( fastlocals = f->f_localsplus; );
把 傳入的參數全部塞進去 fastlocals
那么問題來了,怎么塞?怎么找到傳入了什么鬼參數:這個問題還是只能有 dis 來解答:
我們知道現在這步是在 CALL_FUNCTION 里面進行的,所以塞參數的動作,肯定是在此之前的,所以:
12 27 LOAD_NAME 2 (test) 30 LOAD_CONST 4 (3) 33 CALL_FUNCTION 1 36 POP_TOP 37 LOAD_CONST 1 (None) 40 RETURN_VALUE
在 CALL_FUNCTION 上面就看到 30 LOAD_CONST 4 (3),有興趣的童鞋可以試下多傳幾個參數,就會發現傳入的參數,是依次通過LOAD_CONST 這樣的方式加載進來,所以如何找參數的問題就變得呼之欲出了;
// fast_function 函數 fastlocals = f->f_localsplus; stack = (*pp_stack) - n; for (i = 0; i < n; i++) { Py_INCREF(*stack); fastlocals[i] = *stack++; }
這里出現的 n 還記得怎么來的嗎?回顧上面有個 n = na + 2 * nk; ,能想起什么嗎?
其實這個地方就是簡單的通過將 pp_stack 偏移 n 字節 找到一開始塞入參數的位置。
那么問題來了,如果 n 是 位置參數個數 + 關鍵字參數,那么 2 * nk 是什么意思?其實這答案很簡單,那就是 關鍵字參數字節碼 是屬于帶參數字節碼, 是占 2字節。
到了這里,棧對象 f 的 f_localsplus 也登上歷史舞臺了,只是此時的它,還只是一個未經人事的少年,還需歷練。
做好這些動作,終于來到真正執行函數的地方了: PyEval_EvalFrameEx,在這里,需要先交代下,有個和 PyEval_EvalFrameEx 很像的,叫 PyEval_EvalCodeEx,雖然長得像,但是人家干得活更多了。
請看回前面的 fast_function 開始那會有個判斷,我們上面說得是判斷成立的,也就是最簡單的函數執行情況。如果函數傳入多了關鍵字參數或者其他情況,那就復雜很多了,此時就需要由 PyEval_EvalCodeEx 處理一波,再執行 PyEval_EvalFrameEx。
PyEval_EvalFrameEx 主要的工作就是解析字節碼,像剛才的那些 CALL_FUNCTION,LOAD_FAST 等等,都是由它解析和處理的,它的本質就是一個死循環,然后里面有一堆 swith - case,這基本也就是 Python 的運行本質了。
f_localsplus 存 和 取講了這么長的一堆,算是把 Python 最基本的 函數調用過程簡單掃了個盲,現在才開始探索主題。。
為了簡單闡述,直接引用名詞:fastlocals, 其中 fastlocals = f->f_localsplus
剛才只是簡單看到了,Python 會把傳入的參數,以此塞入 fastlocals 里面去,那么毋庸置疑,傳入的位置參數,必然屬于局部變量了,那么關鍵字參數呢?那肯定也是局部變量,因為它們都被特殊對待了嘛。
那么除了函數參數之外,必然還有函數內部的賦值咯? 這塊字節碼也一早在上面給出了:
# CALL_FUNCTION 5 0 LOAD_CONST 1 ("test") 3 STORE_FAST 1 (c)
這里出現了新的字節碼 STORE_FAST,一起來看看實現把:
# PyEval_EvalFrameEx 龐大 switch-case 的其中一個分支: PREDICTED_WITH_ARG(STORE_FAST); TARGET(STORE_FAST) { v = POP(); SETLOCAL(oparg, v); FAST_DISPATCH(); } # 因為有涉及到宏,就順便給出: #define GETLOCAL(i) (fastlocals[i]) #define SETLOCAL(i, value) do { PyObject *tmp = GETLOCAL(i); GETLOCAL(i) = value; Py_XDECREF(tmp); } while (0)
簡單解釋就是,將 POP() 獲得的值 v,塞到 fastlocals 的 oparg 位置上。此處,v 是 "test", oparg 就是 1。用圖表示就是:
有童鞋可能會突然懵了,為什么突然來了個 b ?我們又需要回到上面看 test 函數是怎樣定義的:
// 我感覺往回看的概率超低的,直接給出算了 def test(b): c = "test" print b # 局部變量 print c # 局部變量
看到函數定義其實都應該知道了,因為 b 是傳的參數啊,老早就塞進去了~
那存儲知道了,那么怎么取呢?同樣也是這段代碼的字節碼:
22 LOAD_FAST 1 (c)
雖然這個用腳趾頭想想都知道原理是啥,但公平起見還是給出相應的代碼:
# PyEval_EvalFrameEx 龐大 switch-case 的其中一個分支: TARGET(LOAD_FAST) { x = GETLOCAL(oparg); if (x != NULL) { Py_INCREF(x); PUSH(x); FAST_DISPATCH(); } format_exc_check_arg(PyExc_UnboundLocalError, UNBOUNDLOCAL_ERROR_MSG, PyTuple_GetItem(co->co_varnames, oparg)); break; }
直接用 GETLOCAL 通過索引在數組里取值了。
到了這里,應該也算是把 f_localsplus 講明白了。這個地方不難,其實一般而言是不會被提及到這個,因為一般來說忽略即可了,但是如果說想在性能方面講究點,那么這個小知識就不得忽視了。
變量使用姿勢因為是面向對象,所以我們都習慣了通過 class 的方式,對于下面的使用方式,也是隨手就來:
class SS(object): def __init__(self): self.test_dict = {} def test(self): print self.test_dict
這種方式一般是沒什么問題的,也很規范。到那時如果是下面的操作,那就有問題了:
class SS(object): def __init__(self): self.test_dict = {} def test(self): num = 10 for i in range(num): self.test_dict[i] = i
這段代碼的性能損耗,會隨著 num 的值增大而增大, 如果下面循環中還要涉及到更多類屬性的讀取、修改等等,那影響就更大了
這個類屬性如果換成 全局變量,也會存在類似的問題,只是說在操作類屬性會比操作全局變量要頻繁得多。
我們直接看看兩者的差距有多大把?
import timeit class SS(object): def test(self): num = 100 self.test_dict = {} # 為了公平,每次執行都同樣初始化新的 {} for i in range(num): self.test_dict[i] = i def test_local(self): num = 100 test_dict = {} # 為了公平,每次執行都同樣初始化新的 {} for i in range(num): test_dict[i] = i self.test_dict = test_dict s = SS() print timeit.timeit(stmt=s.test_local) print timeit.timeit(stmt=s.test)
通過上圖可以看出,隨著 num 的值越大,for 循環的次數就越多,那么兩者的差距也就越大了。
那么為什么會這樣,也是在字節碼可以看出寫端倪:
// s.test >> 28 FOR_ITER 19 (to 50) 31 STORE_FAST 2 (i) 8 34 LOAD_FAST 2 (i) 37 LOAD_FAST 0 (self) 40 LOAD_ATTR 0 (test_dict) 43 LOAD_FAST 2 (i) 46 STORE_SUBSCR 47 JUMP_ABSOLUTE 28 >> 50 POP_BLOCK // s.test_local >> 25 FOR_ITER 16 (to 44) 28 STORE_FAST 3 (i) 14 31 LOAD_FAST 3 (i) 34 LOAD_FAST 2 (test_dict) 37 LOAD_FAST 3 (i) 40 STORE_SUBSCR 41 JUMP_ABSOLUTE 25 >> 44 POP_BLOCK 15 >> 45 LOAD_FAST 2 (test_dict) 48 LOAD_FAST 0 (self) 51 STORE_ATTR 1 (test_dict)
上面兩段就是兩個方法的 for block 內容,大家對比下就會知道, s.test 相比于 s.test_local, 多了個 LOAD_ATTR 放在 FOR_ITER 和 POP_BLOCK 之間。
這說明什么呢? 這說明,在每次循環時,s.test 都需要 LOAD_ATTR,很自然的,我們需要看看這個是干什么的:
TARGET(LOAD_ATTR) { w = GETITEM(names, oparg); v = TOP(); x = PyObject_GetAttr(v, w); Py_DECREF(v); SET_TOP(x); if (x != NULL) DISPATCH(); break; } # 相關宏定義 #define GETITEM(v, i) PyTuple_GetItem((v), (i))
這里出現了一個陌生的變量 name, 這是什么?其實這個就是每個 codeobject 所維護的一個 名字數組,基本上每個塊所使用到的字符串,都會在這里面存著,同樣也是有序的:
// PyCodeObject 結構體成員 PyObject *co_names; /* list of strings (names used) */
那么 LOAD_ATTR 的任務就很清晰了:先從名字列表里面取出字符串,結果就是 "hehe", 然后通過 PyObject_GetAttr 去查找,在這里就是在 s 實例中去查找。
且不說查找效率如何,光多了這一步,都能失之毫厘差之千里了,當然這是在頻繁操作次數比較多的情況下。
所以我們在一些會頻繁操作 類/實例屬性 的情況下,應該是先把 屬性 取出來存到 局部變量,然后用 局部變量 來完成操作。最后視情況把變動更新到 屬性 上。
結語其實相比變量,在函數和方法的使用上面更有學問,更值得探索,因為那個原理和表面看起來差別更大,下次有機會再探討。平時工作多注意下,才能使得我們的 PY 能夠稍微快點點點點點。
歡迎各位大神指點交流, QQ討論群: 258498217
轉載請注明來源: https://segmentfault.com/a/11...
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/42334.html
python在比較新的版本,3.7這個版本中,引入了一個比較新的模塊contextvars,從名字上來看的話,它是形容為上下變量的,下文就給大家詳細的解答下,關于這方面的內容。 Python在3.7的時候引入了一個模塊:contextvars,從名字上很容易看出它指的是上下文變量(Context Variables),所以在介紹contextvars之前我們需要先了解一下什么是上下文(Con...
本文關鍵闡述了處理python遞歸函數及遞歸算法頻次受限制難題,具有非常好的實用價值,希望能幫助到大家。如有誤或者未考慮到真正的地區,望鼎力相助 遞歸函數及遞歸算法頻次受限制 一個函數在外部啟用自身,那么這樣的函數是遞歸函數。遞歸算法要反復應用自身,每遞歸算法一回,越近最后的值。如果一個難題需要由很多類似小問題處理,可以選擇應用遞歸函數。伴隨著遞歸算法的深層次,難題經營規模對比之前都應該所...
本文不會過多講解基礎知識,更多說的是在使用useRef如何能擺脫 這個 閉包陷阱 ? react hooks 的閉包陷阱 基本每個開發員都有遇見,這是很令人抓狂的。 (以下react示范demo,均為react 16.8.3 版本) 列一個具體的場景: functionApp(){ const[count,setCount]=useState(1); useEffect(()=...
小編寫這篇文章的主要目的,就是給大家介紹關于python裝飾器的用途方面的知識,這樣對我們以后的工作也是有一定的幫助,具體用途是什么呢?下面就給各位讀者詳細的解答下。 裝飾器自身的價值顯而易見,可以加強函數值基本功能、簡單化編碼、降低代碼冗余。 它的使用場景同樣很多,比較簡單的場景包含打印日志、統計運行時間,這類例子和用法網上已經很多了: deftime_dec(func): def...
小編寫這篇文章的主要目的,主要是給大家介紹關于python數字圖像處理的一些相關介紹,包括基本的形態學濾波,比如可以使用數字圖像去進行處理類似的形態學濾波。那么,具體的內容呢?下面就給大家詳細解答下。 引言 對圖像進行形態學變換。變換對象一般為灰度圖或二值圖,功能函數放在morphology子模塊內。 1、膨脹(dilation) 原理:一般對二值圖像進行操作。找到像素值為1的點,將它...
閱讀 3318·2019-08-29 16:17
閱讀 1975·2019-08-29 15:31
閱讀 2645·2019-08-29 14:09
閱讀 2548·2019-08-26 13:52
閱讀 744·2019-08-26 12:21
閱讀 2125·2019-08-26 12:08
閱讀 991·2019-08-23 17:08
閱讀 1922·2019-08-23 16:59