• 為犧牲性能追求生產率而吶喊

讓我從關于 Python 中的 asyncio 這個標準庫的討論中休息一會，談談我最近正在思考的一些東西：Python 的速度。對不了解我的人說明一下，我是一個 Python 的粉絲，而且我在我能想到的所有地方都積極地使用 Python。人們對 Python ***的抱怨之一就是它的速度比較慢，有些人甚至拒絕嘗試使用 Python，因為它比其他語言速度慢。這里說說為什么我認為應該嘗試使用 Python，盡管它是有點慢。

速度不再重要

過去的情形是，程序需要花費很長的時間來運行，CPU 比較貴，內存也很貴。程序的運行時間是一個很重要的指標。計算機非常的昂貴，計算機運行所需要的電也是相當貴的。對這些資源進行優化是因為一個永恒的商業法則：

• 優化你最貴的資源。

在過去，最貴的資源是計算機的運行時間。這就是導致計算機科學致力于研究不同算法的效率的原因。然而，這已經不再是正確的，因為現在硅芯片很便宜，確實很便宜。運行時間不再是你最貴的資源。公司最貴的資源現在是它的員工時間。或者換句話說，就是你。把事情做完比把它變快更加重要。實際上，這是相當的重要，我將把它再次放在這里，仿佛它是一個引文一樣(給那些只是粗略瀏覽的人):

• 把事情做完比快速地做事更加重要。

你可能會說：“我的公司在意速度，我開發一個 web 應用程序，那么所有的響應時間必須少于 x 毫秒。”或者，“我們失去了客戶，因為他們認為我們的 app 運行太慢了。”我并不是想說速度一點也不重要，我只是想說速度不再是最重要的東西;它不再是你最貴的資源。

速度是唯一重要的東西

當你在編程的背景下說 速度 時，你通常是說性能，也就是 CPU 周期。當你的 CEO 在編程的背景下說 速度 時，他指的是業務速度，最重要的指標是產品上市的時間。基本上，你的產品/web 程序是多么的快并不重要。它是用什么語言寫的也不重要。甚至它需要花費多少錢也不重要。在一天結束時，讓你的公司存活下來或者死去的唯一事物就是產品上市時間。我不只是說創業公司的想法 -- 你開始賺錢需要花費多久，更多的是“從想法到客戶手中”的時間期限。企業能夠存活下來的唯一方法就是比你的競爭對手更快地創新。如果在你的產品上市之前，你的競爭對手已經提前上市了，那么你想出了多少好的主意也將不再重要。你必須***個上市，或者至少能跟上。一但你放慢了腳步，你就輸了。

• 企業能夠存活下來的唯一方法就是比你的競爭對手更快地創新。

一個微服務的案例

像 Amazon、Google 和 Netflix 這樣的公司明白快速前進的重要性。他們創建了一個業務系統，可以使用這個系統迅速地前進和快速的創新。微服務是針對他們的問題的解決方案。這篇文章不談你是否應該使用微服務，但是至少要理解為什么 Amazon 和 Google 認為他們應該使用微服務。

微服務本來就很慢。微服務的主要概念是用網絡調用來打破邊界。這意味著你正在把使用的函數調用(幾個 cpu 周期)轉變為一個網絡調用。沒有什么比這更影響性能了。和 CPU 相比較，網絡調用真的很慢。但是這些大公司仍然選擇使用微服務。我所知道的架構里面沒有比微服務還要慢的了。微服務***的弊端就是它的性能，但是***的長處就是上市的時間。通過在較小的項目和代碼庫上建立團隊，一個公司能夠以更快的速度進行迭代和創新。這恰恰表明了，非常大的公司也很在意上市時間，而不僅僅只是只有創業公司。

CPU 不是你的瓶頸

如果你在寫一個網絡應用程序，如 web 服務器，很有可能的情況會是，CPU 時間并不是你的程序的瓶頸。當你的 web 服務器處理一個請求時，可能會進行幾次網絡調用，例如到數據庫，或者像 Redis 這樣的緩存服務器。雖然這些服務本身可能比較快速，但是對它們的網絡調用卻很慢。這里有一篇很好的關于特定操作的速度差異的博客文章。在這篇文章里，作者把 CPU 周期時間縮放到更容易理解的人類時間。如果一個單獨的 CPU 周期等同于 1 秒，那么一個從 California 到 New York 的網絡調用將相當于 4 年。那就說明了網絡調用是多少的慢。按一些粗略估計，我們可以假設在同一數據中心內的普通網絡調用大約需要 3 毫秒。這相當于我們“人類比例” 3 個月。現在假設你的程序是高 CPU 密集型，這需要 100000 個 CPU 周期來對單一調用進行響應。這相當于剛剛超過 1 天。現在讓我們假設你使用的是一種要慢 5 倍的語言，這將需要大約 5 天。很好，將那與我們 3 個月的網絡調用時間相比，4 天的差異就顯得并不是很重要了。如果有人為了一個包裹不得不至少等待 3 個月，我不認為額外的 4 天對他們來說真的很重要。

上面所說的***意思是，盡管 Python 速度慢，但是這并不重要。語言的速度(或者 CPU 時間)幾乎從來不是問題。實際上谷歌曾經就這一概念做過一個研究，并且他們就此發表過一篇論文。那篇論文論述了設計高吞吐量的系統。在結論里，他們說到：

在高吞吐量的環境中使用解釋性語言似乎是矛盾的，但是我們已經發現 CPU 時間幾乎不是限制因素;語言的表達性是指，大多數程序是源程序，同時它們的大多數時間花費在 I/O 讀寫和本機的運行時代碼上。而且，解釋性語言無論是在語言層面的輕松實驗還是在允許我們在很多機器上探索分布計算的方法都是很有幫助的，

再次強調：

• CPU 時間幾乎不是限制因素。

如果 CPU 時間是一個問題怎么辦?

你可能會說，“前面說的情況真是太好了，但是我們確實有過一些問題，這些問題中 CPU 成為了我們的瓶頸，并造成了我們的 web 應用的速度十分緩慢”，或者“在服務器上 X 語言比 Y 語言需要更少的硬件資源來運行。”這些都可能是對的。關于 web 服務器有這樣的美妙的事情：你可以幾乎***地負載均衡它們。換句話說，可以在 web 服務器上投入更多的硬件。當然，Python 可能會比其他語言要求更好的硬件資源，比如 c 語言。只是把硬件投入在 CPU 問題上。相比于你的時間，硬件就顯得非常的便宜了。如果你在一年內節省了兩周的生產力時間，那將遠遠多于所增加的硬件開銷的回報。

那么，Python 更快一些嗎?

這一篇文章里面，我一直在談論最重要的是開發時間。所以問題依然存在：當就開發時間而言，Python 要比其他語言更快嗎?按常規慣例來看，我、google 還有其他幾個人可以告訴你 Python 是多么的高效。它為你抽象出很多東西，幫助你關注那些你真正應該編寫代碼的地方，而不會被困在瑣碎事情的雜草里，比如你是否應該使用一個向量或者一個數組。但你可能不喜歡只是聽別人說的這些話，所以讓我們來看一些更多的經驗數據。

在大多數情況下，關于 python 是否是更高效語言的爭論可以歸結為腳本語言(或動態語言)與靜態類型語言兩者的爭論。我認為人們普遍接受的是靜態類型語言的生產力較低，但是，這有一篇優秀的論文解釋了為什么不是這樣。就 Python 而言，這里有一項研究，它調查了不同語言編寫字符串處理的代碼所需要花費的時間，供參考。

在上述研究中，Python 的效率比 Java 高出 2 倍。有一些其他研究也顯示相似的東西。 Rosetta Code 對編程語言的差異進行了深入的研究。在論文中，他們把 python 與其他腳本語言/解釋性語言相比較，得出結論：

• Python 更簡潔，即使與函數式語言相比較(平均要短 1.2 到 1.6 倍)

普遍的趨勢似乎是 Python 中的代碼行總是更少。代碼行聽起來可能像一個可怕的指標，但是包括上面已經提到的兩項研究在內的多項研究表明，每種語言中每行代碼所需要花費的時間大約是一樣的。因此，限制代碼行數就可以提高生產效率。甚至 codinghorror(一名 C# 程序員)本人寫了一篇關于 Python 是如何更有效率的文章。

我認為說 Python 比其他的很多語言更加的有效率是公正的。這主要是由于 Python 有大量的自帶以及第三方庫。如果你不知道為何 Python 是如此的小巧和高效，我邀請你借此機會學習一點 python，自己多實踐。這兒是你的***個程序：

import __hello__ 

但是如果速度真的重要呢?

上述論點的語氣可能會讓人覺得優化與速度一點也不重要。但事實是，很多時候運行時性能真的很重要。一個例子是，你有一個 web 應用程序，其中有一個特定的端點需要用很長的時間來響應。你知道這個程序需要多快，并且知道程序需要改進多少。

在我們的例子中，發生了兩件事：

• 我們注意到有一個端點執行緩慢。
• 我們承認它是緩慢，因為我們有一個可以衡量是否足夠快的標準，而它沒達到那個標準。

我們不必在應用程序中微調優化所有內容，只需要讓其中每一個都“足夠快”。如果一個端點花費了幾秒鐘來響應，你的用戶可能會注意到，但是，他們并不會注意到你將響應時間由 35 毫秒降低到 25 毫秒。“足夠好”就是你需要做到的所有事情。免責聲明: 我應該說有一些應用程序，如實時投標程序，確實需要細微優化，每一毫秒都相當重要。但那只是例外，而不是規則。

為了明白如何對端點進行優化，你的***步將是配置代碼，并嘗試找出瓶頸在哪。畢竟：

• 任何除了瓶頸之外的改進都是錯覺。Any improvements made anywhere besides the bottleneck are an illusion. -- Gene Kim

如果你的優化沒有觸及到瓶頸，你只是浪費你的時間，并沒有解決實際問題。在你優化瓶頸之前，你不會得到任何重要的改進。如果你在不知道瓶頸是什么前就嘗試優化，那么你最終只會在部分代碼中玩耍。在測量和確定瓶頸之前優化代碼被稱為“過早優化”。人們常提及 Donald Knuth 說的話，但他聲稱這句話實際上是他從別人那里聽來的：

• 過早優化是萬惡之源Premature optimization is the root of all evil。

在談到維護代碼庫時，來自 Donald Knuth 的更完整的引文是：

• 在 97% 的時間里，我們應該忘記微不足道的效率：過早的優化是萬惡之源。然而在關 鍵的 3%，我們不應該錯過優化的機會。 —— Donald Knuth

換句話說，他所說的是，在大多數時間你應該忘記對你的代碼進行優化。它幾乎總是足夠好。在不是足夠好的情況下，我們通常只需要觸及 3% 的代碼路徑。比如因為你使用了 if 語句而不是函數，你的端點快了幾納秒，但這并不會使你贏得任何獎項。

過早的優化包括調用某些更快的函數，或者甚至使用特定的數據結構，因為它通常更快。計算機科學認為，如果一個方法或者算法與另一個具有相同的漸近增長(或稱為 Big-O)，那么它們是等價的，即使在實踐中要慢兩倍。計算機是如此之快，算法隨著數據/使用增加而造成的計算增長遠遠超過實際速度本身。換句話說，如果你有兩個 O(log n) 的函數，但是一個要慢兩倍，這實際上并不重要。隨著數據規模的增大，它們都以同樣的速度“慢下來”。這就是過早優化是萬惡之源的原因;它浪費了我們的時間，幾乎從來沒有真正有助于我們的性能改進。

就 Big-O 而言，你可以認為對你的程序而言，所有的語言都是 O(n)，其中 n 是代碼或者指令的行數。對于同樣的指令，它們以同樣的速率增長。對于漸進增長，一種語言的速度快慢并不重要，所有語言都是相同的。在這個邏輯下，你可以說，為你的應用程序選擇一種語言僅僅是因為它的“快速”是過早優化的最終形式。你選擇某些預期快速的東西，卻沒有測量，也不理解瓶頸將在哪里。

• 為您的應用選擇語言只是因為它的“快速”，是過早優化的最終形式。

優化 Python

我最喜歡 Python 的一點是，它可以讓你一次優化一點點代碼。假設你有一個 Python 的方法，你發現它是你的瓶頸。你對它優化過幾次，可能遵循這里和那里的一些指導，現在，你很肯定 Python 本身就是你的瓶頸。Python 有調用 C 代碼的能力，這意味著，你可以用 C 重寫這個方法來減少性能問題。你可以一次重寫一個這樣的方法。這個過程允許你用任何可以編譯為 C 兼容匯編程序的語言，編寫良好優化后的瓶頸方法。這讓你能夠在大多數時間使用 Python 編寫，只在必要的時候都才用較低級的語言來寫代碼。

有一種叫做 Cython 的編程語言，它是 Python 的超集。它幾乎是 Python 和 C 的合并，是一種漸進類型的語言。任何 Python 代碼都是有效的 Cython 代碼，Cython 代碼可以編譯成 C 代碼。使用 Cython，你可以編寫一個模塊或者一個方法，并逐漸進步到越來越多的 C 類型和性能。你可以將 C 類型和 Python 的鴨子類型混在一起。使用 Cython，你可以獲得混合后的***組合，只在瓶頸處進行優化，同時在其他所有地方不失去 Python 的美麗。

當您最終遇到 Python 的性能問題阻礙時，你不需要把你的整個代碼庫用另一種不同的語言來編寫。你只需要用 Cython 重寫幾個函數，幾乎就能得到你所需要的性能。這就是星戰前夜采取的策略。這是一個大型多玩家的電腦游戲，在整個架構中使用 Python 和 Cython。它們通過優化 C/Cython 中的瓶頸來實現游戲級別的性能。如果這個策略對他們有用，那么它應該對任何人都有幫助。或者，還有其他方法來優化你的 Python。例如，PyPy 是一個 Python 的 JIT 實現，它通過使用 PyPy 替掉 CPython(這是 Python 的默認實現)，為長時間運行的應用程序提供重要的運行時改進(如 web 服務器)。

讓我們回顧一下要點：

• 優化你最貴的資源。那就是你，而不是計算機。
• 選擇一種語言/框架/架構來幫助你快速開發(比如 Python)。不要僅僅因為某些技術的快而選擇它們。
• 當你遇到性能問題時，請找到瓶頸所在。
• 你的瓶頸很可能不是 CPU 或者 Python 本身。
• 如果 Python 成為你的瓶頸(你已經優化過你的算法)，那么可以轉向熱門的 Cython 或者 C。
• 盡情享受可以快速做完事情的樂趣。

我希望你喜歡閱讀這篇文章，就像我喜歡寫這篇文章一樣。如果你想說謝謝，請為我點下贊。另外，如果某個時候你想和我討論 Python，你可以在 twitter 上艾特我(@nhumrich)，或者你可以在 Python slack channel 找到我。

作者簡介：

Nick Humrich -- 堅持采用持續交付的方法，并為之寫了很多工具。同是還是一名 Python 黑客與技術狂熱者，目前是一名 DevOps 工程師。