??“Python貓” ，一個值得加星標的公眾號花下貓語：最近，讀者微信群里又頻繁聊到了 Python 的性能問題，這真是老生常談了。我想起自己曾收藏過幾篇關于如何提升性能的文章，似乎挺有幫助的，便去聯系了下作者，現在已經取得轉載授權啦。今天分享其中一篇，后續還會有其它相關分享，希望對讀者們也有所幫助。作者：CeruleanW

原文：https://zhuanlan.zhihu.com/p/60992622

圖 | 《側耳傾聽》劇照

背景

這篇文章的背景是在最近的工作中涉及到了一些計算密集型任務，這些計算密集型任務或多或少觸發了一些之前幾乎沒有關心過的Python性能問題，所以寫下這篇文章分析Python的性能問題，并調研了一些對應的改善方案(Numba、Cython)。

坦白地說，在過往用Objective-C寫iOS應用的經歷中，除了一些面試和工作中常見的關于一些UI組件渲染的性能問題外，幾乎沒有關心過代碼執行的效率(性能)問題。這次也正好是一個契機使我有機會復習一些本科學過的知識。

二維數組求和

首先讓我們看一段簡單的Python代碼，這段代碼定義了一個函數，其功能是對一個np.ndarray類型的二維數組求和，并返回結果：

def?arr_sum(src_arr):
????res?=?0
????shape?=?src_arr.shape
????for?r?in?range(0,?shape[0]):
????????for?c?in?range(0,?shape[1]):
????????????res?+=?src_arr[r][c]
????return?res

這段代碼沒什么特別的，如果我們的src_arr.shape是128x128，上面這個代碼片段執行1000次，在我的機器上(i7 6700K、32G)，大概需要3.7857s，同樣的，沒有對比就沒有傷害，同樣的代碼，如果我們用C++重寫一下，大概會是這個樣子：

double?sum(double?arr[][128],?int?row)?{
????double?res?=?0;
????for?(int?i?=?0;?i?????????for?(int?j?=?0;?j?128;?++j)?{
????????????res?+=?arr[i][j];
????????}
????}
????return?res;
}

這段代碼的執行時間將會是0.035s，即大約35ms，可以看出，在這個場景下(當然，在實際的項目或者研究中，根據問題規模的不同，某個代碼片段的實現也會不盡相同)，還是可以有一個粗糙的結論：大概Python比C++慢了100倍。

雖然這個結論不是非常嚴謹，例如，我們出于某種面向對象的考慮，希望這段代碼不是非常的膠水，可能會用std::vector或者某些容器替換一個C風格的二維數組：

template<typename?T>
T?sum(vector<vector>&?arr,?int?row,?int?col)?{
????T?res?=?0;
????for?(int?i?=?0;?i?????????for?(int?j?=?0;?j?????????????res?+=?arr[row][col];
????????}
????}
????return?res;
}

而上面這段粗糙的實現對應的執行時間將會是0.060s，即60ms，但是仍然要比Python快出兩個數量級，依然沒有問題。

甚至如果你不幸將：

T?sum(vector<vector>&?arr,?int?row,?int?col)

寫成了：

T?sum(vector<vector>?arr,?int?row,?int?col)

而導致函數調用時復制整個二維數組，也只需要4.3s，而對比Python的3.75s，反而會感覺還沒慢多少。

為什么Python慢？

那么為什么Python會顯得慢呢？首先，Python通常被稱作解釋型語言，是相對于像C++這樣的編譯型語言來說的。

事實上py文件也會被編譯，但是并不像C++，或者是其他靜態強類型編譯型語言那樣，通過預處理、編譯、匯編、鏈接這樣的過程最終得到機器碼。py文件，即Python的源代碼通常會在運行時被解釋器先解釋為字節碼，然后交由虛擬機將字節碼翻譯成機器碼執行，而這一步就很尬了。

事實上，也正是因為這樣，我們往往才因此獲得Python在運行時一些非常強大的特性，例如generator，利用generator我們可以做一些非常神奇的事情，例如協程等。

但是另一方面，Python的解釋器和虛擬機翻譯并執行字節碼的過程帶來了很大的性能開銷，一個直覺的解釋是：由于沒有原生的編譯時類型檢查，所有的類型的檢查都被移交給了運行時，執行一行Python代碼很可能需要做不只一行的類型檢查、邊界檢查等等。

這里其實并不打算詳細探究Python字節碼的編譯與執行，只是簡單的通過一個例子大致說明一行Python代碼是如何被解釋和執行的，

考慮源文件test.py，他們的實現很簡單，其中test.py的實現大概是這樣的：

def?add(x,?y):
????res?=?x?+?y
????print('Res:?'?+?res)

如你所見的，計算兩個值的和，然后將結果打印到標準輸出。

我們通過dis模塊將test.py翻譯成可讀的字節碼指令，將會是這樣：

Disassembly?of?add:
??2???????????0?LOAD_FAST????????????????0?(x)
??????????????3?LOAD_FAST????????????????1?(y)
??????????????6?BINARY_ADD
??????????????7?STORE_FAST???????????????2?(res)
??3??????????10?LOAD_GLOBAL??????????????0?(print)
?????????????13?LOAD_CONST???????????????1?('Res:?')
?????????????16?LOAD_FAST????????????????2?(res)
?????????????19?BINARY_ADD
?????????????20?CALL_FUNCTION????????????1?(1?positional,?0?keyword?pair)
?????????????23?POP_TOP
?????????????24?LOAD_CONST???????????????0?(None)
?????????????27?RETURN_VALUE

即，首先Python的源代碼py文件將會被解釋器翻譯成上類似上面的東西，但是具體可能會更加復雜一點，但是我想到這一步應該已經能說明一些問題了，然后這個字節碼會被Python虛擬機嘗試執行，而在執行時則會有很多運行時的檢查，然后才是轉化為真正的機器碼交由CPU執行。

而C++就不同了，因為他沒有這一步。

其實，字節碼也不是每次都是從磁盤讀py文件在運行時編譯的，事實上，每個在運行時被編譯的py文件將會產生PyCodeObject對象，這一步操作是在解釋import語句時執行的，PyCodeObject對象創建后，一方面將會根據需要被虛擬機繼續轉化為PyFrameObject對象進行后續的機器碼翻譯和執行工作，另一方面會帶著一個“最后修改日期”的字段被緩存在磁盤上，通常，這個位置是在源代碼同級目錄下__pycache__文件夾中，這些被緩存的PyCodeObject對象將與源文件同名，只是擴展名為pyc，以便下次運行時直接讀取緩存，從而節約編譯字節碼的時間。

所以，一個粗糙的結論可能是這樣的，Python由于要在運行時編譯和解釋執行字節碼，而且這個過程中參與了很多類似運行時類型檢查的操作等一系列其他操作，從而產生了很多額外開銷，降低了性能。

如何提速？

那么如何提速？在本文我們調研了兩種方案，分別是Numba和Cython，接下來我們將分別簡述它們的加速原理，并給出一些示例代碼，并做一些簡單的性能對比實驗。

Numba

首先我們介紹Numba，先引一段官網文檔的介紹：

Numba is a just-in-time compiler for Python that works best on code that uses NumPy arrays and functions, and loops. The most common way to use Numba is through its collection of decorators that can be applied to your functions to instruct Numba to compile them. When a call is made to a Numba decorated function it is compiled to machine code “just-in-time” for execution and all or part of your code can subsequently run at native machine code speed!

其中有兩句話比較重要：

Numba is a just-in-time compiler for Python that works best on code that uses NumPy arrays and functions, and loops.

Numba是一個JIT編譯器，它和Numpy的數組和函數以及循環一起用時，效果最佳。

另一句是：

When a call is made to a Numba decorated function it is compiled to machine code “just-in-time” for execution and all or part of your code can subsequently run at native machine code speed!

如果一個調用被Numba裝飾器修飾，那么它將被JIT機制編譯成機器碼執行，性能堪比本地機器碼的速度。

同樣，它的原理簡介也能在官網文檔中找到：

Numba reads the Python bytecode for a decorated function and combines this with information about the types of the input arguments to the function. It analyzes and optimizes your code, and finally uses the LLVM compiler library to generate a machine code version of your function, tailored to your CPU capabilities. This compiled version is then used every time your function is called.

簡要的概括即是，Numba通過一個裝飾器讀某些調用的字節碼，并為它們的參數等添加類型信息，嘗試優化代碼后，通過LLVM編譯器直接生成對應的機器碼。

思想其實很明確，一方面是在字節碼被執行前添加類型信息，然后省去原始調用的字節碼被執行的過程，通過LLVM直接編譯機器碼，從而節省了性能開銷，事實也確實如此。

通過引入numba模塊，原始的Python代碼將會被改寫成這樣：

import?numba?as?nb

@nb.njit()
def?arr_sum(src_arr):
????res?=?0
????shape?=?src_arr.shape
????for?r?in?range(0,?shape[0]):
????????for?c?in?range(0,?shape[1]):
????????????res?+=?src_arr[r][c]
????return?res

可以發現其實沒什么變化，除了加了一個@nb.njit()的裝飾器外，沒有對原函數做任何改動，這其實也是numba的方便之處(與后續的Cython方案對比)，事實上@nb.njit()會盡其所能去尋找能被numba的JIT機制添加類型信息并翻譯成機器碼的對象，如果失敗了，運行起來的效果甚至會比原始的Python代碼還慢。

在它的文檔的開頭也就提到，它和Numpy的數組和函數以及循環一起用時，效果最佳，同時文檔也給出了一個暫時不支持pandas類型的例子。

詳細的numba實現原理已經超出了本文做簡單調研的范圍，可能我們會有后續幾篇文章討論這個問題。

一個快速的入門文檔可以參見：

https://numba.pydata.org/numba-doc/latest/user/5minguide.html

最后，添加numba裝飾器后，代碼片段對大小為128x128的二維數組求和，運行1000次時間為0.017122s，即17ms，比CXX還要快。

而JIT首次嘗試編譯求和函數代碼的約為0.151606s，即150ms，所以，一個粗糙的結論是，如果這段代碼確實性能開銷較大，且被調用頻率相對較高，那么一個短暫的編譯時間還是可以被接受的。

Cython

接下來我們介紹Cython，

Cython是在Python中實現C-Extensions的一種方案，簡單的理解是，Python提供了一些與CXX的Lib相互調用的機制，而能通過import作為模塊來進行調用的C或者C++的Lib，就是C-Extensions，有很多方案可以用來實現C-Extensions，例如Swig等，而Cython就是其中一種。

同樣引一段官方文檔中關于Cython的介紹：

Cython is an optimising static compiler for both the Python programming language and the extended Cython programming language (based on Pyrex). It makes writing C extensions for Python as easy as Python itself.

它的核心精神是，Cython將Cython語言(一種基于Python的擴展語言)寫的pyx文件直接編譯成C extensions，從而獲得近乎于寫CXX語言的性能。

我們直接看一個Cython改寫的二維數組求和代碼片段，這個代碼片段的文件名將會是func.pyx，可以注意到到與*.py結尾的文件不同，Cython的代碼將是以pyx結尾。

cimport?cython
@cython.boundscheck(False)
@cython.wraparound(False)

def?arr_sum(double[:,?:]?src_arr):

????cdef?double?res?=?0
????cdef?Py_ssize_t[:]?shape?=?src_arr.shape

????cdef?Py_ssize_t?r?=?0
????cdef?Py_ssize_t?c?=?0

????for?r?in?range(0,?shape[0]):
????????for?c?in?range(0,?shape[1]):
????????????res?+=?src_arr[r][c]
????return?res

我們用了一些cdef關鍵字，來在定義變量時指明它們的類型，同時，我們使用了形如double[:, :]這樣的關鍵字，它代表了Python中的MemoryView，即內存視圖。簡而言之，內存視圖可以快速索引值，通過內存視圖，我們可以避開繁瑣的Python對象引用流程，直接訪問一個二維數組某個下標值，如果不經轉置，它在內存上應該是連續的，永遠是通過一個基地址加上一個偏移量。

Cython文檔在Typed Memory Views一節詳細的介紹了這個機制，這里就不在贅述了。

https://cython.readthedocs.io/en/latest/src/userguide/memoryviews.html

看上去我們在寫帶類型標識符的Python，實際上這些代碼都會被Cython先解釋稱CXX，然后編譯成.so(Linux)，通過編寫對應的setup.py：

from?distutils.core?import?setup
from?Cython.Build?import?cythonize

setup(
????ext_modules=cythonize(["playground/cyfunc/func.pyx"],?annotate=True)
)

打開annotate=True，Cython會替我們生成一份源碼分析，如下圖，詳細的展示了pyx文件是如何生成CXX代碼的，同時，黃色對應的行說明這行有Python調用，可能會影響能：

img

通過這種方式，代碼片段對大小為128x128的二維數組求和，運行1000次時間為0.0181s，約18ms。

性能對比

最后我們給出了四組實驗的結果，代碼片段對大小為128x128的二維數組求和，運行1000次時間如下：

Total?cost?time?for?func:?py_func,?call?1000?times:?3.803216s.
Total?cost?time?for?func:?np_func,?call?1000?times:?0.343562s.
Total?cost?time?for?func:?nb_func,?call?1000?times:?0.017122s.
Total?cost?time?for?func:?cy_func,?call?1000?times:?0.018159s.

它們分別代表了原始Python、Numpy、Numba、Cython對應的性能。

需要注意的是，numba的編譯時間約為150ms：

Time?cost?for?numba?first?call:?0.151606s.

希望在之后的幾篇文章中，討論Numba與Cython的實現細節。

Python提升之路，推薦閱讀

1

深度辨析 Python 的 eval() 與 exec()

2

Python進階：設計模式之迭代器模式

3

Python進階：全面解讀高級特性之切片！

4

Python 工匠：讓函數返回結果的技巧

---

文章分享完了，最后是隨機薦書環節。我會根據文章內容，提出一個關鍵詞(這篇是“高性能”)來搜索，隨機選擇一兩本技術書推薦給大家，如果你感興趣的話，可以點擊鏈接進行了解。希望能給大家帶來不經意的收獲~~

告訴朋友們，我在看

總結

以上是生活随笔為你收集整理的just函数python_提升 Python 性能 Numba 与 Cython的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。