標籤：

代碼優化指南：人生苦短，我用Python

01-28

選自pythonfiles

機器之心編譯

參與：Panda

前段時間，Python Files 博客發布了幾篇主題為「Hunting Performance in Python Code」的系列文章，對提升 Python 代碼的性能的方法進行了介紹。在其中的每一篇文章中，作者都會介紹幾種可用於 Python 代碼的工具和分析器，以及它們可以如何幫助你更好地在前端（Python 腳本）和/或後端（Python 解釋器）中找到瓶頸。機器之心對這個系列文章進行了整理編輯，將其融合成了這一篇深度長文。本文的相關代碼都已經發布在 GitHub 上。

代碼地址：github.com/apatrascu/hu

第一部分請查看從環境設置到內存分析。以下是 Python 代碼優化的第二部分，主要從 Python 腳本與 Python 解釋器兩個方面闡述。在這一部分中我們首先會關注如何追蹤 Python 腳本的 CPU 使用情況，並重點討論 cProfile、line_profiler、pprofile 和 vprof。而後一部分重點介紹了一些可用於在運行 Python 腳本時對解釋器進行性能分析的工具和方法，主要討論了 CPython 和 PyPy 等。

CPU 分析——Python 腳本

在這一節，我將介紹一些有助於我們解決 Python 中分析 CPU 使用的難題的工具。

CPU 性能分析（profiling）的意思是通過分析 CPU 執行代碼的方式來分析這些代碼的性能。也就是說要找到我們代碼中的熱點（hot spot），然後看我們可以怎麼處理它們。

接下來我們會看看你可以如何追蹤你的 Python 腳本的 CPU 使用。我們將關注以下分析器（profiler）：

  • cProfile
  • line_profiler
  • pprofile
  • vprof

測量 CPU 使用

這一節我將使用與前一節基本一樣的腳本，你也可以在 GitHub 上查看：gist.github.com/apatras

另外，記住在 PyPy2 上，你需要使用一個支持它的 pip 版本：

其它東西可以通過以下指令安裝：

cProfile

在 CPU 性能分析上最常用的一個工具是 cProfile，主要是因為它內置於 CPython2 和 PyPy2 中。這是一個確定性的分析器，也就是說它會在運行我們的負載時收集一系列統計數據，比如代碼各個部分的執行次數或執行時間。此外，相比於其它內置的分析器（profile 或 hotshot），cProfile 對系統的開銷更少。

當使用 CPython2 時，其使用方法是相當簡單的：

如果你使用的是 PyPy2：

其輸出如下：

即使是這樣的文本輸出，我們也可以直接看到我們腳本的大多數時間都在調用 list.append 方法。

如果我們使用 gprof2dot，我們可以用圖形化的方式來查看 cProfile 的輸出。要使用這個工具，我們首先必須安裝 graphviz。在 Ubuntu 上，可以使用以下命令：

再次運行我們的腳本：

然後我們會得到下面的 output.png 文件：

這樣看起來就輕鬆多了。讓我們仔細看看它輸出了什麼。你可以看到來自腳本的函數調用圖（callgraph）。在每個方框中，你可以一行一行地看到：

  • 第一行：Python 文件名、行數和方法名
  • 第二行：這個方框所用的時間佔全局時間的比例
  • 第三行：括弧中是該方法本身所用時間佔全局時間的比例
  • 第四行：調用次數

比如說，在從上到下第三個紅色框中，方法 primes 佔用了 98.28% 的時間，65.44% 的時間是在該方法之中做什麼事情，它被調用了 40 次。剩下的時間被用在了 Python 的 list.append（22.33%）和 range（11.51%）方法中。

這是一個簡單的腳本，所以我們只需要重寫我們的腳本，讓它不用使用那麼多的 append 方法，結果如下：

以下測試了腳本在使用前和使用 CPython2 後的運行時間：

用 PyPy2 測量：

我們在 CPython2 上得到了 2.4 倍的提升，在 PyPy2 上得到了 3.1 倍的提升。很不錯，其 cProfile 調用圖為：

你也可以以程序的方式查看 cProfile：

這在一些場景中很有用，比如多進程性能測量。更多詳情請參閱：docs.python.org/2/libra

line_profiler

這個分析器可以提供逐行水平的負載信息。這是通過 C 語言用 Cython 實現的，與 cProfile 相比計算開銷更少。

其源代碼可在 GitHub 上獲取：github.com/rkern/line_p，PyPI 頁面為：pypi.python.org/pypi/li。和 cProfile 相比，它有相當大的開銷，需要多 12 倍的時間才能得到一個分析結果。

要使用這個工具，你首先需要通過 pip 添加：pip install pip install Cython ipython==5.4.1 line_profiler（CPython2）。這個分析器的一個主要缺點是不支持 PyPy。

就像在使用 memory_profiler 時一樣，你需要在你想分析的函數上加上一個裝飾。在我們的例子中，你需要在 03.primes-v1.py 中的 primes 函數的定義前加上 @profile。然後像這樣調用：

你會得到一個這樣的輸出：

我們可以看到兩個循環在反覆調用 list.append，佔用了腳本的大部分時間。

pprofile

地址：github.com/vpelletier/p

據作者介紹，pprofile 是一個「行粒度的、可感知線程的確定性和統計性純 Python 分析器」。

它的靈感來源於 line_profiler，修復了大量缺陷，但因為其完全是用 Python 寫的，所以也可以通過 PyPy 使用。和 cProfile 相比，使用 CPython 時分析的時間會多 28 倍，使用 PyPy 時的分析時間會長 10 倍，但具有粒度更大的細節水平。

而且還支持 PyPy 了！除此之外，它還支持線程分析，這在很多情況下都很有用。

要使用這個工具，你首先需要通過 pip 安裝：pip install pprofile（CPython2）/ pypy -m pip install pprofile（PyPy），然後像這樣調用：

其輸出和前面工具的輸出不同，如下：

我們現在可以看到更詳細的細節。讓我們稍微研究一下這個輸出。這是這個腳本的整個輸出，每一行你可以看到調用的次數、運行它所用的時間（秒）、每次調用的時間和佔全局時間的比例。此外，pprofile 還為我們的輸出增加了額外的行（比如 44 和 50 行，行前面寫著 (call）)，這是累積指標。

同樣，我們可以看到有兩個循環在反覆調用 list.append，佔用了腳本的大部分時間。

vprof

地址：github.com/nvdv/vprof

vprof 是一個 Python 分析器，為各種 Python 程序特點提供了豐富的互動式可視化，比如運行時間和內存使用。這是一個圖形化工具，基於 Node.JS，可在網頁上展示結果。

使用這個工具，你可以針對相關 Python 腳本查看下面的一項或多項內容：

  • CPU flame graph
  • 代碼分析（code profiling）
  • 內存圖（memory graph）
  • 代碼熱圖（code heatmap）

要使用這個工具，你首先需要通過 pip 安裝：pip install vprof（CPython2）/ pypy -m pip install vprof（PyPy），然後像這樣調用：

在 CPython2 上，要顯示代碼熱圖（下面的第一行調用）和代碼分析（下面的第二行調用）：

在 PyPy 上，要顯示代碼熱圖（下面的第一行調用）和代碼分析（下面的第二行調用）：

在上面的兩個例子中，你都會看到如下的代碼熱圖：

以及如下的代碼分析：

結果是以圖形化的方式展示的，你可以將滑鼠懸浮或點擊每一行，從而查看更多信息。同樣，我們可以看到有兩個循環在反覆調用 list.append 方法，佔用了腳本的大部分時間。

CPU 分析——Python 解釋器

在這一節，我將介紹一些可用於在運行 Python 腳本時對解釋器進行性能分析的工具和方法。

正如前幾節提到的，CPU 性能分析的意義是一樣的，但現在我們的目標不是 Python 腳本。我們現在想要知道 Python 解釋器的工作方式，以及 Python 腳本運行時在哪裡消耗的時間最多。

接下來我們將看到你可以怎樣跟蹤 CPU 使用情況以及找到解釋器中的熱點。

測量 CPU 使用情況

這一節所使用的腳本基本上和前面內存分析和腳本 CPU 使用情況分析時使用的腳本一樣，你也可以在這裡查閱代碼：gist.github.com/apatras

優化後的版本見下面或訪問：gist.github.com/apatras

CPython

CPython 的功能很多，這是完全用 C 語言寫的，因此在測量和/或性能分析上可以更加容易。你可以找到託管在 GitHub 上的 CPython 資源：github.com/python/cpyth。默認情況下，你會看到最新的分支，在本文寫作時是 3.7+ 版本，但向前一直到 2.7 版本的分支都能找到。

在這篇文章中，我們的重點是 CPython 2，但最新的第 3 版也可成功應用同樣的步驟。

1. 代碼覆蓋工具（Code coverage tool）

要查看正在運行的 C 語言代碼是哪一部分，最簡單的方法是使用代碼覆蓋工具。

首先我們克隆這個代碼庫：

複製該目錄中的腳本並運行以下命令：

第一行代碼將會使用 GCOV 支持（gcc.gnu.org/onlinedocs/）編譯該解釋器，第二行將運行負載並收集在 .gcda 文件中的分析數據，第三行代碼將解析包含這些分析數據的文件並在名為 lcov-report 的文件夾中創建一些 HTML 文件。

如果我們在瀏覽器中打開 index.html，我們會看到為了運行我們的 Python 腳本而執行的解釋器源代碼的位置。你會看到類似下面的東西：

在上面一層，我們可以看到構成該源代碼的每個目錄以及被覆蓋的代碼的量。舉個例子，讓我們從 Objects 目錄打開 listobject.c.gcov.html 文件。儘管我們不會完全看完這些文件，但我們會分析其中一部分。看下面這部分。

怎麼讀懂其中的信息？在黃色一列，你可以看到 C 語言文件代碼的行數。接下來一列是特定一行代碼執行的次數。最右邊一列是實際的 C 語言源代碼。

在這個例子中，listiter_next 方法被調用了 6000 萬次。

我們怎麼找到這個函數？如果我們仔細看看我們的 Python 腳本，我們可以看到它使用了大量的列表迭代和 append。（這是另一個可以一開始就做腳本優化的地方。）

讓我們繼續看看其它一些專用工具。在 Linux 系統上，如果我們想要更多信息，我們可以使用 perf。官方文檔可參閱：perf.wiki.kernel.org/in

我們使用下面的代碼重建了 CPython 解釋器。你應該將這個 Python 腳本下載到同一個目錄。另外，要確保你的系統安裝了 perf。

如下運行 perf。使用 perf 的更多方式可以看 Brendan Gregg 寫的這個：brendangregg.com/perf.h

運行腳本後，你會看到下述內容：

要查看結果，運行 sudo perf report 獲取指標。

只有最相關的調用會被保留。在上面的截圖中，我們可以看到佔用時間最多的是 PyEval_EvalFrameEx。這是其中的主解釋器循環，在這個例子中，我們對此並不關心。我們感興趣的是下一個耗時的函數 listiter_next，它佔用了 10.70% 的時間。

在運行了優化的版本之後，我們可以看到以下結果：

在我們優化之後，listiter_next 函數的時間佔用降至了 2.11%。讀者還可以探索對該解釋器進行進一步的優化。

2. Valgrind/Callgrind

另一個可用於尋找瓶頸的工具是 Valgrind，它有一個被稱為 callgrind 的插件。更多細節請參閱：valgrind.org/docs/manua

我們使用下面的代碼重建了 CPython 解釋器。你應該將這個 Python 腳本下載到同一個目錄。另外，確保你的系統安裝了 valgrind。

按下面方法運行 valgrind：

結果如下：

我們使用 KCacheGrind 進行了可視化：kcachegrind.sourceforge.net

PyPy

在 PyPy 上，可以成功使用的分析器是非常有限的。PyPy 的開發者為此開發了工具 vmprof：vmprof.readthedocs.io/e

首先，你要下載 PyPy：pypy.org/download.html。在此之後，為其啟用 pip 支持。

安裝 vmprof 的方式很簡單，運行以下代碼即可：

按以下方式運行工作負載：

然後在瀏覽器中打開顯示在控制台中的鏈接（以 vmprof.com/# 開頭的鏈接）。

原文鏈接：

pythonfiles.wordpress.com

pythonfiles.wordpress.com


推薦閱讀：

※由淺入深寫代理(3) -socks5 代理
※Python數據分析及可視化實例之文本處理文本相似度（29）
※玩點好玩的--知乎全部話題關係可視化（Docker+Flask+Bootstrap+echarts+uWSGI+Nginx）

TAG:Python |