問題：Python的總體性能較慢，有限的線程與孱弱的多處理能力成為其未來發展的主要障礙。

Python長期以來一直更重視編程速度，而非運行速度。考慮到很多開發者習慣于利用C或C++編寫高速外部庫(例如NumPy或者Numba)以執行Python下的性能密集型任務，這樣的權衡似乎也沒什么大不了。但問題在于，Python的開箱性能仍然落后于其它語法同樣簡單、但能夠編譯為機器碼的語言，例如Nim或者Julia。

Python當中歷史最悠久的性能問題之一，在于其對多核心或處理器的資源使用能力不佳。雖然Python確實具有線程功能，但卻僅限于單一核心。此外，Python也會嘗試通過啟動其運行時的子實例以支持多處理，但是針對這些子進程結果的調度與同步往往效率不高。

解決方案：目前，還沒有某一種自上而下的整體性解決方案，能夠直接搞定Python的性能問題。不過，現在已經出現了一系列用于加速Python的嘗試，其各自都在特定領域做出了一定改進。

下面來看例子：

改善CPython的內部行為。CPython改進帶來了幅度有限但卻覆蓋面廣泛的加速效果。例如，Python3.8的Vectorcall協議為Python對象帶來了更快的調用約定。雖然改進效果不算顯著，但足以帶來具有可測量且可預測的性能提升，而且完全不會破壞向下兼容性;此外，現有Python應用程序可直接受益，無需任何代碼重寫。

改進CPython的子解釋器功能。Python解釋器實例的新編程接口現在可以時在各解釋器之間實現優雅的數據共享，從而實現多核處理。現在，這項提案已經確定將在Python3.9中面世，相信其還將在后續版本中繼續發揮重要作用。

改進多個進程之間的對象共享。Python當中的多處理機制會為每個核心啟動一個新的解釋器實例，用以獲取最佳性能;但當多個解釋器嘗試對同一內存對象進行操作時，大部分性能提升都會瞬間作廢。目前，以SahredMemory類以及新的pickle協議為代表的新功能，可以減少解釋器之間數據傳遞所需要的復制或者序列化過程，從根本上消除相關性能問題。

在Python之外，也有不少外部項目帶來了新的性能提升方法——但同樣僅限于特定問題：

PyPy。另一種Python解釋器，PyPy能夠將Python即時編譯為本機機器碼。它在純Python項目當中發揮出色，現在也能很好地兼容比較流行的二進制相關庫——例如NumPy。但其一般更適合長期運行的服務，而非一次性應用程序。

Cython。Cython允許用戶逐步將Python代碼轉換為C代碼。該項目最初是專為科學與數值計算所設計的，但卻能夠在大多數場景下起效。Cython最大的缺點在于語法，其使用了獨有的語法設置，且轉換只能單向進行。Cython最適合處理“熱點”部分代碼，這種有針對性的優化方式往往比應用程序整體優化要更合理、也更可行。

Numba。Numba的即時編譯功能可以面向選定功能將Python代碼編譯為機器碼。與Cython類似，Numba同樣主要用于科學計算，其比較適合就地運行而非對代碼進行重新發布。

Mypyc。Mypyc項目目前仍在開發當中，其希望將帶有mypy類型注釋的Python代碼轉換為C代碼。Mypyc很有前途，因為其使用到Python中的眾多原生類型，但目前距離生產應用還有很長的路要走。

經過優化的Python發行版。某些第三方Python版本(例如英特爾的Python發行版)擁有可充分發揮英特爾處理器擴展(例如AVX512)優勢的數學與統計庫。需要注意的是，盡管其能夠顯著加快特定數學函數的執行速度，但卻無法實現全面的速度提升。

有經驗的Python程序員一定還會提到全局解釋器鎖(GIL)的問題，其負責對指向對象的訪問進行序列化，以確保不同線程不會彼此影響到對方的工作負載。從理論上講，放棄GIL可以提高性能。然而，無GILPython基本上喪失了向下兼容能力(特別是在PythonC擴展方面)。因此到目前為止，所有移除GIL的嘗試要么已經走進死胡同，要么反而降低了Python的性能。

目前另一個正在推進的Python計劃有望解決不少速度方面的問題，即重構Python內部的CAPI實現。眾長遠來看，提升API集的有序程度可以帶來諸多性能改進：重新設計或者剔除GIL、提供可實現強大即時編譯的hook、在解釋器實例之間使用更好的數據聯合方法等等。

以上內容為大家介紹了Python多線程與速度，希望對大家有所幫助，如果想要了解更多Python相關知識，請關注IT培訓機構:千鋒教育。http://www.dietsnews.net/