當我們提到一門編程語言的效率時：通常有兩層意思，第一是開發效率，這是對程序員而言，完成編碼所需要的時間；另一個是運行效率，這是對計算機而言，完成計算任務所需要的時間。編碼效率和運行效率往往是魚與熊掌的關系，是很難同時兼顧的。不同的語言會有不同的側重，python語言毫無疑問更在乎編碼效率，life is short，we use python。

雖然使用python的編程人員都應該接受其運行效率低的事實，但python在越多越來的領域都有廣泛應用，比如科學計算 、web服務器等。程序員當然也希望python能夠運算得更快，希望python可以更強大。

首先，python相比其他語言具體有多慢，這個不同場景和測試用例，結果肯定是不一樣的。這個網址給出了不同語言在各種case下的性能對比，這一頁是python3和C++的對比，下面是兩個case：

從上圖可以看出，不同的case，python比C++慢了幾倍到幾十倍。

python運算效率低，具體是什么原因呢，下列羅列一些：

第一：python是動態語言

一個變量所指向對象的類型在運行時才確定，編譯器做不了任何預測，也就無從優化。舉一個簡單的例子：　r = a + b。　a和b相加，但a和b的類型在運行時才知道，對于加法操作，不同的類型有不同的處理，所以每次運行的時候都會去判斷a和b的類型，然后執行對應的操作。而在靜態語言如C++中，編譯的時候就確定了運行時的代碼。

另外一個例子是屬性查找，關于具體的查找順序在《python屬性查找》中有詳細介紹。簡而言之，訪問對象的某個屬性是一個非常復雜的過程，而且通過同一個變量訪問到的python對象還都可能不一樣（參見Lazy property的例子）。而在C語言中，訪問屬性用對象的地址加上屬性的偏移就可以了。

第二：python是解釋執行，但是不支持JIT（just in time compiler）。雖然大名鼎鼎的google曾經嘗試Unladen Swallow 這個項目，但最終也折了。

第三：python中一切都是對象，每個對象都需要維護引用計數，增加了額外的工作。

第四：python GIL，GIL是Python最為詬病的一點，因為GIL，python中的多線程并不能真正的并發。如果是在IO bound的業務場景，這個問題并不大，但是在CPU BOUND的場景，這就很致命了。所以筆者在工作中使用python多線程的情況并不多，一般都是使用多進程（pre fork），或者在加上協程。即使在單線程，GIL也會帶來很大的性能影響，因為python每執行100個opcode（默認，可以通過sys.setcheckinterval()設置）就會嘗試線程的切換，具體的源代碼在ceval.c::PyEval_EvalFrameEx。

第五：垃圾回收，這個可能是所有具有垃圾回收的編程語言的通病。python采用標記和分代的垃圾回收策略，每次垃圾回收的時候都會中斷正在執行的程序，造成所謂的頓卡。infoq上有一篇文章，提到禁用Python的GC機制后，Instagram性能提升了10%。感興趣的讀者可以去細讀。

內容擴展

關于python運行效率的分析：

如果每次你創建一個應用程序都是用相同的編碼方法，幾乎肯定會導致一些你的應用程序比它能夠達到的運行效率慢的情況。作為分析過程的一部分，你可以嘗試一些實驗。例如，在一個字典中管理一些元素，你可以采用安全的方法確定元素是否已經存在并更新，或者你可以直接添加元素，然后作為異常處理該元素不存在情況。考慮第一個編碼的例子：

n = 16myDict = {}for i in range(0, n): char = ’abcd’[i%4] if char not in myDict: myDict[char] = 0 myDict[char] += 1 print(myDict)

這段代碼通常會在myDict開始為空時運行得更快。然而，當mydict通常被數據填充（或者至少大部分被充填）時，另一種方法效果更好。

n = 16myDict = {}for i in range(0, n): char = ’abcd’[i%4] try: myDict[char] += 1 except KeyError: myDict[char] = 1 print(myDict)

兩種情況下具有相同的輸出：{‘d’: 4, ‘c’: 4, ‘b’: 4, ‘a’: 4}。唯一的不同是這個輸出是如何得到的。跳出固定的思維模式，創造新的編碼技巧，能夠幫助你利用你的應用程序獲得更快的結果。