• 為犧牲性能追求生產(chǎn)率而吶喊

讓我從關(guān)于 Python 中的 asyncio 這個(gè)標(biāo)準(zhǔn)庫(kù)的討論中休息一會(huì)，談?wù)勎易罱谒伎嫉囊恍〇|西：Python 的速度。對(duì)不了解我的人說(shuō)明一下，我是一個(gè) Python 的粉絲，而且我在我能想到的所有地方都積極地使用 Python。人們對(duì) Python ***的抱怨之一就是它的速度比較慢，有些人甚至拒絕嘗試使用 Python，因?yàn)樗绕渌Z(yǔ)言速度慢。這里說(shuō)說(shuō)為什么我認(rèn)為應(yīng)該嘗試使用 Python，盡管它是有點(diǎn)慢。

速度不再重要

過(guò)去的情形是，程序需要花費(fèi)很長(zhǎng)的時(shí)間來(lái)運(yùn)行，CPU 比較貴，內(nèi)存也很貴。程序的運(yùn)行時(shí)間是一個(gè)很重要的指標(biāo)。計(jì)算機(jī)非常的昂貴，計(jì)算機(jī)運(yùn)行所需要的電也是相當(dāng)貴的。對(duì)這些資源進(jìn)行優(yōu)化是因?yàn)橐粋€(gè)永恒的商業(yè)法則：

• 優(yōu)化你最貴的資源。

在過(guò)去，最貴的資源是計(jì)算機(jī)的運(yùn)行時(shí)間。這就是導(dǎo)致計(jì)算機(jī)科學(xué)致力于研究不同算法的效率的原因。然而，這已經(jīng)不再是正確的，因?yàn)楝F(xiàn)在硅芯片很便宜，確實(shí)很便宜。運(yùn)行時(shí)間不再是你最貴的資源。公司最貴的資源現(xiàn)在是它的員工時(shí)間。或者換句話說(shuō)，就是你。把事情做完比把它變快更加重要。實(shí)際上，這是相當(dāng)?shù)闹匾?，我將把它再次放在這里，仿佛它是一個(gè)引文一樣(給那些只是粗略瀏覽的人):

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

你可能會(huì)說(shuō)：“我的公司在意速度，我開發(fā)一個(gè) web 應(yīng)用程序，那么所有的響應(yīng)時(shí)間必須少于 x 毫秒。”或者，“我們失去了客戶，因?yàn)樗麄冋J(rèn)為我們的 app 運(yùn)行太慢了。”我并不是想說(shuō)速度一點(diǎn)也不重要，我只是想說(shuō)速度不再是最重要的東西;它不再是你最貴的資源。

速度是唯一重要的東西

當(dāng)你在編程的背景下說(shuō) 速度 時(shí)，你通常是說(shuō)性能，也就是 CPU 周期。當(dāng)你的 CEO 在編程的背景下說(shuō) 速度 時(shí)，他指的是業(yè)務(wù)速度，最重要的指標(biāo)是產(chǎn)品上市的時(shí)間。基本上，你的產(chǎn)品/web 程序是多么的快并不重要。它是用什么語(yǔ)言寫的也不重要。甚至它需要花費(fèi)多少錢也不重要。在一天結(jié)束時(shí)，讓你的公司存活下來(lái)或者死去的唯一事物就是產(chǎn)品上市時(shí)間。我不只是說(shuō)創(chuàng)業(yè)公司的想法 -- 你開始賺錢需要花費(fèi)多久，更多的是“從想法到客戶手中”的時(shí)間期限。企業(yè)能夠存活下來(lái)的唯一方法就是比你的競(jìng)爭(zhēng)對(duì)手更快地創(chuàng)新。如果在你的產(chǎn)品上市之前，你的競(jìng)爭(zhēng)對(duì)手已經(jīng)提前上市了，那么你想出了多少好的主意也將不再重要。你必須***個(gè)上市，或者至少能跟上。一但你放慢了腳步，你就輸了。

• 企業(yè)能夠存活下來(lái)的唯一方法就是比你的競(jìng)爭(zhēng)對(duì)手更快地創(chuàng)新。

一個(gè)微服務(wù)的案例

像 Amazon、Google 和 Netflix 這樣的公司明白快速前進(jìn)的重要性。他們創(chuàng)建了一個(gè)業(yè)務(wù)系統(tǒng)，可以使用這個(gè)系統(tǒng)迅速地前進(jìn)和快速的創(chuàng)新。微服務(wù)是針對(duì)他們的問題的解決方案。這篇文章不談你是否應(yīng)該使用微服務(wù)，但是至少要理解為什么 Amazon 和 Google 認(rèn)為他們應(yīng)該使用微服務(wù)。

微服務(wù)本來(lái)就很慢。微服務(wù)的主要概念是用網(wǎng)絡(luò)調(diào)用來(lái)打破邊界。這意味著你正在把使用的函數(shù)調(diào)用(幾個(gè) cpu 周期)轉(zhuǎn)變?yōu)橐粋€(gè)網(wǎng)絡(luò)調(diào)用。沒有什么比這更影響性能了。和 CPU 相比較，網(wǎng)絡(luò)調(diào)用真的很慢。但是這些大公司仍然選擇使用微服務(wù)。我所知道的架構(gòu)里面沒有比微服務(wù)還要慢的了。微服務(wù)***的弊端就是它的性能，但是***的長(zhǎng)處就是上市的時(shí)間。通過(guò)在較小的項(xiàng)目和代碼庫(kù)上建立團(tuán)隊(duì)，一個(gè)公司能夠以更快的速度進(jìn)行迭代和創(chuàng)新。這恰恰表明了，非常大的公司也很在意上市時(shí)間，而不僅僅只是只有創(chuàng)業(yè)公司。

CPU 不是你的瓶頸

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

上面所說(shuō)的***意思是，盡管 Python 速度慢，但是這并不重要。語(yǔ)言的速度(或者 CPU 時(shí)間)幾乎從來(lái)不是問題。實(shí)際上谷歌曾經(jīng)就這一概念做過(guò)一個(gè)研究，并且他們就此發(fā)表過(guò)一篇論文。那篇論文論述了設(shè)計(jì)高吞吐量的系統(tǒng)。在結(jié)論里，他們說(shuō)到：

在高吞吐量的環(huán)境中使用解釋性語(yǔ)言似乎是矛盾的，但是我們已經(jīng)發(fā)現(xiàn) CPU 時(shí)間幾乎不是限制因素;語(yǔ)言的表達(dá)性是指，大多數(shù)程序是源程序，同時(shí)它們的大多數(shù)時(shí)間花費(fèi)在 I/O 讀寫和本機(jī)的運(yùn)行時(shí)代碼上。而且，解釋性語(yǔ)言無(wú)論是在語(yǔ)言層面的輕松實(shí)驗(yàn)還是在允許我們?cè)诤芏鄼C(jī)器上探索分布計(jì)算的方法都是很有幫助的，

再次強(qiáng)調(diào)：

• CPU 時(shí)間幾乎不是限制因素。

如果 CPU 時(shí)間是一個(gè)問題怎么辦?

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

那么，Python 更快一些嗎?

這一篇文章里面，我一直在談?wù)撟钪匾氖情_發(fā)時(shí)間。所以問題依然存在：當(dāng)就開發(fā)時(shí)間而言，Python 要比其他語(yǔ)言更快嗎?按常規(guī)慣例來(lái)看，我、google 還有其他幾個(gè)人可以告訴你 Python 是多么的高效。它為你抽象出很多東西，幫助你關(guān)注那些你真正應(yīng)該編寫代碼的地方，而不會(huì)被困在瑣碎事情的雜草里，比如你是否應(yīng)該使用一個(gè)向量或者一個(gè)數(shù)組。但你可能不喜歡只是聽別人說(shuō)的這些話，所以讓我們來(lái)看一些更多的經(jīng)驗(yàn)數(shù)據(jù)。

在大多數(shù)情況下，關(guān)于 python 是否是更高效語(yǔ)言的爭(zhēng)論可以歸結(jié)為腳本語(yǔ)言(或動(dòng)態(tài)語(yǔ)言)與靜態(tài)類型語(yǔ)言兩者的爭(zhēng)論。我認(rèn)為人們普遍接受的是靜態(tài)類型語(yǔ)言的生產(chǎn)力較低，但是，這有一篇優(yōu)秀的論文解釋了為什么不是這樣。就 Python 而言，這里有一項(xiàng)研究，它調(diào)查了不同語(yǔ)言編寫字符串處理的代碼所需要花費(fèi)的時(shí)間，供參考。

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

• Python 更簡(jiǎn)潔，即使與函數(shù)式語(yǔ)言相比較(平均要短 1.2 到 1.6 倍)

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

我認(rèn)為說(shuō) Python 比其他的很多語(yǔ)言更加的有效率是公正的。這主要是由于 Python 有大量的自帶以及第三方庫(kù)。如果你不知道為何 Python 是如此的小巧和高效，我邀請(qǐng)你借此機(jī)會(huì)學(xué)習(xí)一點(diǎn) python，自己多實(shí)踐。這兒是你的***個(gè)程序：

import __hello__ 

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

上述論點(diǎn)的語(yǔ)氣可能會(huì)讓人覺得優(yōu)化與速度一點(diǎn)也不重要。但事實(shí)是，很多時(shí)候運(yùn)行時(shí)性能真的很重要。一個(gè)例子是，你有一個(gè) web 應(yīng)用程序，其中有一個(gè)特定的端點(diǎn)需要用很長(zhǎng)的時(shí)間來(lái)響應(yīng)。你知道這個(gè)程序需要多快，并且知道程序需要改進(jìn)多少。

在我們的例子中，發(fā)生了兩件事：

• 我們注意到有一個(gè)端點(diǎn)執(zhí)行緩慢。
• 我們承認(rèn)它是緩慢，因?yàn)槲覀冇幸粋€(gè)可以衡量是否足夠快的標(biāo)準(zhǔn)，而它沒達(dá)到那個(gè)標(biāo)準(zhǔn)。

我們不必在應(yīng)用程序中微調(diào)優(yōu)化所有內(nèi)容，只需要讓其中每一個(gè)都“足夠快”。如果一個(gè)端點(diǎn)花費(fèi)了幾秒鐘來(lái)響應(yīng)，你的用戶可能會(huì)注意到，但是，他們并不會(huì)注意到你將響應(yīng)時(shí)間由 35 毫秒降低到 25 毫秒。“足夠好”就是你需要做到的所有事情。免責(zé)聲明: 我應(yīng)該說(shuō)有一些應(yīng)用程序，如實(shí)時(shí)投標(biāo)程序，確實(shí)需要細(xì)微優(yōu)化，每一毫秒都相當(dāng)重要。但那只是例外，而不是規(guī)則。

為了明白如何對(duì)端點(diǎn)進(jìn)行優(yōu)化，你的***步將是配置代碼，并嘗試找出瓶頸在哪。畢竟：

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

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

• 過(guò)早優(yōu)化是萬(wàn)惡之源Premature optimization is the root of all evil。

在談到維護(hù)代碼庫(kù)時(shí)，來(lái)自 Donald Knuth 的更完整的引文是：

• 在 97% 的時(shí)間里，我們應(yīng)該忘記微不足道的效率：過(guò)早的優(yōu)化是萬(wàn)惡之源。然而在關(guān) 鍵的 3%，我們不應(yīng)該錯(cuò)過(guò)優(yōu)化的機(jī)會(huì)。 —— Donald Knuth

換句話說(shuō)，他所說(shuō)的是，在大多數(shù)時(shí)間你應(yīng)該忘記對(duì)你的代碼進(jìn)行優(yōu)化。它幾乎總是足夠好。在不是足夠好的情況下，我們通常只需要觸及 3% 的代碼路徑。比如因?yàn)槟闶褂昧?if 語(yǔ)句而不是函數(shù)，你的端點(diǎn)快了幾納秒，但這并不會(huì)使你贏得任何獎(jiǎng)項(xiàng)。

過(guò)早的優(yōu)化包括調(diào)用某些更快的函數(shù)，或者甚至使用特定的數(shù)據(jù)結(jié)構(gòu)，因?yàn)樗ǔ８臁Ｓ?jì)算機(jī)科學(xué)認(rèn)為，如果一個(gè)方法或者算法與另一個(gè)具有相同的漸近增長(zhǎng)(或稱為 Big-O)，那么它們是等價(jià)的，即使在實(shí)踐中要慢兩倍。計(jì)算機(jī)是如此之快，算法隨著數(shù)據(jù)/使用增加而造成的計(jì)算增長(zhǎng)遠(yuǎn)遠(yuǎn)超過(guò)實(shí)際速度本身。換句話說(shuō)，如果你有兩個(gè) O(log n) 的函數(shù)，但是一個(gè)要慢兩倍，這實(shí)際上并不重要。隨著數(shù)據(jù)規(guī)模的增大，它們都以同樣的速度“慢下來(lái)”。這就是過(guò)早優(yōu)化是萬(wàn)惡之源的原因;它浪費(fèi)了我們的時(shí)間，幾乎從來(lái)沒有真正有助于我們的性能改進(jìn)。

就 Big-O 而言，你可以認(rèn)為對(duì)你的程序而言，所有的語(yǔ)言都是 O(n)，其中 n 是代碼或者指令的行數(shù)。對(duì)于同樣的指令，它們以同樣的速率增長(zhǎng)。對(duì)于漸進(jìn)增長(zhǎng)，一種語(yǔ)言的速度快慢并不重要，所有語(yǔ)言都是相同的。在這個(gè)邏輯下，你可以說(shuō)，為你的應(yīng)用程序選擇一種語(yǔ)言僅僅是因?yàn)樗?ldquo;快速”是過(guò)早優(yōu)化的最終形式。你選擇某些預(yù)期快速的東西，卻沒有測(cè)量，也不理解瓶頸將在哪里。

• 為您的應(yīng)用選擇語(yǔ)言只是因?yàn)樗?ldquo;快速”，是過(guò)早優(yōu)化的最終形式。

優(yōu)化 Python

我最喜歡 Python 的一點(diǎn)是，它可以讓你一次優(yōu)化一點(diǎn)點(diǎn)代碼。假設(shè)你有一個(gè) Python 的方法，你發(fā)現(xiàn)它是你的瓶頸。你對(duì)它優(yōu)化過(guò)幾次，可能遵循這里和那里的一些指導(dǎo)，現(xiàn)在，你很肯定 Python 本身就是你的瓶頸。Python 有調(diào)用 C 代碼的能力，這意味著，你可以用 C 重寫這個(gè)方法來(lái)減少性能問題。你可以一次重寫一個(gè)這樣的方法。這個(gè)過(guò)程允許你用任何可以編譯為 C 兼容匯編程序的語(yǔ)言，編寫良好優(yōu)化后的瓶頸方法。這讓你能夠在大多數(shù)時(shí)間使用 Python 編寫，只在必要的時(shí)候都才用較低級(jí)的語(yǔ)言來(lái)寫代碼。

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

當(dāng)您最終遇到 Python 的性能問題阻礙時(shí)，你不需要把你的整個(gè)代碼庫(kù)用另一種不同的語(yǔ)言來(lái)編寫。你只需要用 Cython 重寫幾個(gè)函數(shù)，幾乎就能得到你所需要的性能。這就是星戰(zhàn)前夜采取的策略。這是一個(gè)大型多玩家的電腦游戲，在整個(gè)架構(gòu)中使用 Python 和 Cython。它們通過(guò)優(yōu)化 C/Cython 中的瓶頸來(lái)實(shí)現(xiàn)游戲級(jí)別的性能。如果這個(gè)策略對(duì)他們有用，那么它應(yīng)該對(duì)任何人都有幫助?；蛘?，還有其他方法來(lái)優(yōu)化你的 Python。例如，PyPy 是一個(gè) Python 的 JIT 實(shí)現(xiàn)，它通過(guò)使用 PyPy 替掉 CPython(這是 Python 的默認(rèn)實(shí)現(xiàn))，為長(zhǎng)時(shí)間運(yùn)行的應(yīng)用程序提供重要的運(yùn)行時(shí)改進(jìn)(如 web 服務(wù)器)。

讓我們回顧一下要點(diǎn)：

• 優(yōu)化你最貴的資源。那就是你，而不是計(jì)算機(jī)。
• 選擇一種語(yǔ)言/框架/架構(gòu)來(lái)幫助你快速開發(fā)(比如 Python)。不要僅僅因?yàn)槟承┘夹g(shù)的快而選擇它們。
• 當(dāng)你遇到性能問題時(shí)，請(qǐng)找到瓶頸所在。
• 你的瓶頸很可能不是 CPU 或者 Python 本身。
• 如果 Python 成為你的瓶頸(你已經(jīng)優(yōu)化過(guò)你的算法)，那么可以轉(zhuǎn)向熱門的 Cython 或者 C。
• 盡情享受可以快速做完事情的樂趣。

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

作者簡(jiǎn)介：

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