Python很慢和/或它不是的兩個最常見的原因高性能：

解讀
GIL
第一個是相當直接的，但在高級別編譯器將更高級別的語言翻譯成更低級別（更快）的語言，因此編譯語言幾乎總是比非編譯語言執(zhí)行得更快。這個經驗法則有一些例外（例如JIT可能比AOT編譯更快的情況），但它們會分散討論。

第二個是更臭名昭著，但是Python有一個叫做全局解釋器鎖的東西，它通過強制解釋器一次只在一個進程（Python解釋器的實例）中執(zhí)行單個線程來基本上防止多線程。它的工作原理也很有趣，但也像編譯器一樣切入兔子洞。

Python性能下降9/10倍并不重要。

隨著時間的推移，我認為有兩個主要原因。

首先，重要的不是代碼執(zhí)行時間，而是最終用戶體驗。它不一般的問題，如果一個函數(shù)具有0.001秒或0.01來執(zhí)行。在這種情況下，對于大多數(shù)問題，可以使用水平擴展來解決Python創(chuàng)建的許多瓶頸。

以這些基準為例對于流行的Web框架。使用Python的最好的是650.5K req / s，而最好的數(shù)字是2.2M。純粹從性能的角度來看，你可能想知道為什么你不會選擇最快的，但是你看看那個＃1點并意識到它正在使用C. C是一種很棒的語言（IMO），但是Python很多更具表現(xiàn)力，擁有更大的生態(tài)系統(tǒng)，您可以選擇使用預先構建的工具。因此，在犧牲開發(fā)時間/范圍的同時，不是從服務器中擠出最后一點計算能力，而是可以為每1個需要C的服務器獲得4臺Python服務器，并節(jié)省開發(fā)人員生產力和開發(fā)時間的許多倍。這顯然是一個戲劇性和極其簡化的例子，但我認為這一點是合理的。

這讓我們圍繞GIL的第二個實現(xiàn)和我的結論，它確實并沒有那么糟糕。

通過不允許多線程（或在同一進程中同時執(zhí)行），Python大大簡化了開發(fā)人員面臨的編程復雜性。 開發(fā)人員可以忽略多線程進程的常見 問題和優(yōu)化，因為Python解釋器一次只能執(zhí)行一個邏輯。

這也通常不會多大關系為同一水平推理點1而不是解決與多線程問題，您可以選擇與解決問題的多重處理。您可以啟動多個進程并在它們之間進行通信，而不是在單個進程中管理多個線程。差異很微妙，但同樣，對于這些情況中的9/10，多處理與線程的性能開銷并不重要。

在頭頂性能的情況下做的事情，你可以隨時“膠水”不同的語言為你的Python邏輯。典型的例子是Numpy如何通過放入C將高性能數(shù)組結構數(shù)據(jù)結構帶到Python。

那么這一切又是什么呢？

隨著計算能力（處理器核心的數(shù)量，單個核心的速度，服務器硬件的成本等）越來越便宜，大多數(shù)性能問題通常可以通過水平擴展來解決。

對于你無法橫向解決的事情，你可以用不同的語言寫一些東西并將其“粘合”到你的Python邏輯中（假設Python是一種“膠水”語言）。

因此，如果最終可以增強/處理性能，那么您需要將Python作為一種語言的主要原因：

簡單
生產的
可讀（從而更易于維護）

關于Python的優(yōu)點和缺點，我們可以談論更多的內容，我們可以更詳細地討論，但我認為這是解決為什么Python解釋器性能不會影響其受歡迎程度的問題的良好開端。

            
              文章來于quora