未編譯 Python 代碼比 Go 慢 100 倍

原文連結

在我看來，編譯型代碼有兩個明顯的優勢：

每次修改代碼都可以得到驗證，甚至是在開始運作代碼之前。

更快的執行速度。根據具體情況，代碼可能被編譯成非常底層的運作指令。

我之是以要寫這篇文章，是想比較一下編譯型代碼的執行速度會比解釋型快多少。

因為我偏愛編譯型程式設計語言，是以現在有個問題：我手頭有很多感興趣的代碼，但它們都是用 Python 寫的，我該怎麼辦？全部重寫？部分重寫？完全不重寫？

先入之見

在這篇文章裡，我通過比較 Java 、 Go 和 Python 在處理不同任務時的性能表現來驗證我對它們的一些先入之見。首先是 Python，我正在考慮要不要把它替換掉。至于 Java，我已經是 20 多年的粉絲了，一路看着它成熟，不管是性能還是功能都在變得更好。最後是 Go，我兩年前才開始用它，但真的很喜歡它。雖然 Go 相比 Java 還缺失了一些特性，比如類繼承，但它的文法簡潔而緊湊，編譯和執行速度都很快，生成的代碼也很緊湊，還提供了優雅的 goroutine 來實作并發處理。

以下是我的一些先入之見。

編譯型代碼的執行速度比解釋型代碼要快一個數量級。之前，我比較了使用 JIT 和不使用 JIT 編譯 Java 代碼所獲得的性能，它們的比率大概是 30 比 1。

Go 的運作速度比 Java 要快一點。我記得在之前的工作中做過一些測試，發現 Go 在處理某些任務時要比 Java 快 30%，但最近一些文章又說 Java 比 Go 快。

先來測試一把我在之前的一篇文章中通過一些代碼比較過 JIT 的性能，後來使用 Python 和 Go 也實作了一遍。這段代碼計算 100 的 Fibonacci 數值，每一輪計算 50 次，并列印執行時間（納秒），共計算 200 輪。代碼可以在 GitHub 上找到。

三種語言的輸出結果看起來像這樣：

複制代碼

Java   Go    Python
...
122    123   11683
119    107   11539
123    104   11358
120    115   11926
119    118   11973
120    104   11377
109    103   12960
127    122   15683
112    106   11482
...
           

平均值是這樣：

Java   Go    Python
130    105   10050
           

可以看到，在計算 Fibonacci 數值時，Java 比 Go 要慢一些，大概慢 24%，而 Python 幾乎慢了 100 倍，也就是 9458%。

這個結果驗證了我最初對 Java 和 Go 的判斷，但讓我感到吃驚的是 Python 的表現，它慢得不隻是一個數量級，是兩個！

我在想 Python 為什麼會花這麼多時間。

我首先想到的是，很多人關注的是 Python 的易用性，并通過犧牲性能來快速獲得處理結果。我相信資料科學家們都是這麼想的。況且有這麼多現成的庫可以用，為什麼要去找其他的？遲早會有人優化它們的。

第二個原因是很多人沒有比較過不同的實作，因為很多初創公司在激烈的競争中忙于做出産品，根本無暇顧及什麼優化不優化。

第三個原因，有一些方式可以讓同樣的 Python 代碼跑得更快。

把 Python 代碼編譯一下會如何

在做了一些調研之後，我決定使用 PyPy 測試一下相同的 Python 代碼。PyPy 是 Python 的另一個實作，它本身就是使用 Python 開發的，包含了一個像 Java 那樣的 JIT 編譯器。跟 Java 一樣，我們需要忽略初始的輸出，并跳過 JIT 編譯過程，得到的結果如下：

Java   Go    Python    PyPy
130    105   10050     1887
           

PyPy 的平均響應速度比 Python 快 5 倍，但仍然比 Go 慢 20 倍。

更多的測試

以上的測試主要集中在數值的計算上，如果回到最開始所說的 Python 代碼，我還需要關注：

Kafka、HTTP 監聽器和資料庫的 IO；

解析 JSON 消息。

總結

本文通過執行簡單的數學運算得出這樣的結論：Go 的執行速度比 Java 快一些，比解釋運作的 Python 快 2 個數量級。

基于這樣的結果，我個人是不會使用 Go 來替換 Java 的。

另一方面，在高負載的關鍵任務上使用 Python 不是一個好的選擇。如果你正面臨這種情況，可以考慮使用 Python 編譯器作為短期的應急方案。

在決定是否要重寫 Python 代碼時，還需要考慮到其他因素，比如 IO 和 CPU 方面的問題，但這些超出本文的範圍了。

有人提醒我，使用 Go 和 Java 的 64 位整型隻能準确計算出 92 的 Fibonacci 數值，再往後會出現溢出（譯者：是以代碼後來改成了計算 90 的 Fibonacci 數值）。但即使是這樣，本文的結論仍然是有效的。