為什麼 Python 這麼慢？

2018-10-27 12:39:29 Linux中國

編譯自： https://hackernoon.com/why-is-python-so-slow-e5074b6fe55b

Python 現在越來越火，已經迅速擴張到包括 DevOps、數據科學、Web 開發、信息安全等各個領域當中。

然而，相比起 Python 擴張的速度，Python 代碼的運行速度就顯得有點遜色了。

在代碼運行速度方面，Java、C、C++、C# 和 Python 要如何進行比較呢？並沒有一個放之四海而皆準的標準，因為具體結果很大程度上取決於運行的程序類型，而語言基準測試(Computer Language Benchmarks Games)可以作為衡量的一個方面。

根據我這些年來進行語言基準測試的經驗來看，Python 比很多語言運行起來都要慢。無論是使用 JIT 編譯器的 C＃、Java，還是使用 AOT 編譯器的 C、C++，又或者是 JavaScript 這些解釋型語言，Python 都比它們運行得慢。

注意：對於文中的 “Python” ，一般指 CPython 這個官方的實現。當然我也會在本文中提到其它語言的 Python 實現。

我要回答的是這個問題：對於一個類似的程序，Python 要比其它語言慢 2 到 10 倍不等，這其中的原因是什麼？又有沒有改善的方法呢？

主流的說法有這些：

“是全局解釋器鎖(Global Interpreter Lock)（GIL）的原因”
“是因為 Python 是解釋型語言而不是編譯型語言”
“是因為 Python 是一種動態類型的語言”

哪一個才是是影響 Python 運行效率的主要原因呢？

是全局解釋器鎖的原因嗎？

現在很多計算機都配備了具有多個核的 CPU ，有時甚至還會有多個處理器。為了更充分利用它們的處理能力，操作系統定義了一個稱為線程的低級結構。某一個進程（例如 Chrome 瀏覽器）可以建立多個線程，在系統內執行不同的操作。在這種情況下，CPU 密集型進程就可以跨核心分擔負載了，這樣的做法可以大大提高應用程序的運行效率。

例如在我寫這篇文章時，我的 Chrome 瀏覽器打開了 44 個線程。需要提及的是，基於 POSIX 的操作系統（例如 Mac OS、Linux）和 Windows 操作系統的線程結構、API 都是不同的，因此操作系統還負責對各個線程的調度。

如果你還沒有寫過多線程執行的代碼，你就需要了解一下線程鎖的概念了。多線程進程比單線程進程更為複雜，是因為需要使用線程鎖來確保同一個內存地址中的數據不會被多個線程同時訪問或更改。

CPython 解釋器在創建變量時，首先會分配內存，然後對該變量的引用進行計數，這稱為引用計數(reference counting)。如果變量的引用數變為 0，這個變量就會從內存中釋放掉。這就是在 for 循環代碼塊內創建臨時變量不會增加內存消耗的原因。

而當多個線程內共享一個變量時，CPython 鎖定引用計數的關鍵就在於使用了 GIL，它會謹慎地控制線程的執行情況，無論同時存在多少個線程，解釋器每次只允許一個線程進行操作。

這會對 Python 程序的性能有什麼影響？

如果你的程序只有單線程、單進程，代碼的速度和性能不會受到全局解釋器鎖的影響。

但如果你通過在單進程中使用多線程實現併發，並且是 IO 密集型（例如網絡 IO 或磁盤 IO）的線程，GIL 競爭的效果就很明顯了。

由 David Beazley 提供的 GIL 競爭情況圖 http://dabeaz.blogspot.com/2010/01/python-gil-visualized.html

對於一個 web 應用（例如 Django），同時還使用了 WSGI，那麼對這個 web 應用的每一個請求都運行一個單獨的 Python 解釋器，而且每個請求只有一個鎖。同時因為 Python 解釋器的啟動比較慢，某些 WSGI 實現還具有“守護進程模式”，可以使 Python 進程一直就緒。

其它的 Python 解釋器表現如何？

PyPy 也是一種帶有 GIL 的解釋器，但通常比 CPython 要快 3 倍以上。

Jython 則是一種沒有 GIL 的解釋器，這是因為 Jython 中的 Python 線程使用 Java 線程來實現，並且由 JVM 內存管理系統來進行管理。

JavaScript 在這方面又是怎樣做的呢？

所有的 Javascript 引擎使用的都是 mark-and-sweep 垃圾收集算法，而 GIL 使用的則是 CPython 的內存管理算法。

JavaScript 沒有 GIL，而且它是單線程的，也不需要用到 GIL， JavaScript 的事件循環和 Promise/Callback 模式實現了以異步編程的方式代替併發。在 Python 當中也有一個類似的 asyncio 事件循環。

是因為 Python 是解釋型語言嗎？

我經常會聽到這個說法，但是這過於粗陋地簡化了 Python 所實際做的工作了。其實當終端上執行 python myscript.py 之後，CPython 會對代碼進行一系列的讀取、語法分析、解析、編譯、解釋和執行的操作。

如果你對這一系列過程感興趣，也可以閱讀一下我之前的文章：在 6 分鐘內修改 Python 語言。

.pyc 文件的創建是這個過程的重點。在代碼編譯階段，Python 3 會將字節碼序列寫入 __pycache__/ 下的文件中，而 Python 2 則會將字節碼序列寫入當前目錄的 .pyc 文件中。對於你編寫的腳本、導入的所有代碼以及第三方模塊都是如此。

因此，絕大多數情況下（除非你的代碼是一次性的……），Python 都會解釋字節碼並本地執行。與 Java、C#.NET 相比：

Java 代碼會被編譯為“中間語言”，由 Java 虛擬機讀取字節碼，並將其即時編譯為機器碼。.NET CIL 也是如此，.NET CLR（Common-Language-Runtime）將字節碼即時編譯為機器碼。

既然 Python 像 Java 和 C# 那樣都使用虛擬機或某種字節碼，為什麼 Python 在基準測試中仍然比 Java 和 C# 慢得多呢？首要原因是，.NET 和 Java 都是 JIT 編譯的。

即時(Just-in-time)（JIT）編譯需要一種中間語言，以便將代碼拆分為多個塊（或多個幀）。而提前(ahead of time)（AOT）編譯器則需要確保 CPU 在任何交互發生之前理解每一行代碼。

JIT 本身不會使執行速度加快，因為它執行的仍然是同樣的字節碼序列。但是 JIT 會允許在運行時進行優化。一個優秀的 JIT 優化器會分析出程序的哪些部分會被多次執行，這就是程序中的“熱點”，然後優化器會將這些代碼替換為更有效率的版本以實現優化。

這就意味著如果你的程序是多次重複相同的操作時，有可能會被優化器優化得更快。而且，Java 和 C# 是強類型語言，因此優化器對代碼的判斷可以更為準確。

PyPy 使用了明顯快於 CPython 的 JIT。更詳細的結果可以在這篇性能基準測試文章中看到：哪一個 Python 版本最快? 。

那為什麼 CPython 不使用 JIT 呢？

JIT 也不是完美的，它的一個顯著缺點就在於啟動時間。 CPython 的啟動時間已經相對比較慢，而 PyPy 比 CPython 啟動還要慢 2 到 3 倍。Java 虛擬機啟動速度也是出了名的慢。.NET CLR 則通過在系統啟動時啟動來優化體驗，而 CLR 的開發者也是在 CLR 上開發該操作系統。

因此如果你有個長時間運行的單一 Python 進程，JIT 就比較有意義了，因為代碼裡有“熱點”可以優化。

不過，CPython 是個通用的實現。設想如果使用 Python 開發命令行程序，但每次調用 CLI 時都必須等待 JIT 緩慢啟動，這種體驗就相當不好了。

CPython 試圖用於各種使用情況。有可能實現將 JIT 插入到 CPython 中，但這個改進工作的進度基本處於停滯不前的狀態。

如果你想充分發揮 JIT 的優勢，請使用 PyPy。