python 這門編程語言的運行速度並不快,這早已不是什麼秘密了。很多開發者期待這門語言的性能有所提升,這種情況或即將發生改變,或至少朝着正確的方向前進着,這也是Python的創始人重新出山後的決策結果之一。
5月7日,Python團隊發布最新的 Python 版本 - Python 3.11。目前發布的是一個測試版本 (Beta1) ,供開發者們測試或實驗時使用。

按照開發團隊的所定下規約,預計將於 2022 年 10 月正式版本將釋出。
有好奇網友在自己的虛擬機上進行了測試,他在單獨的 Docker 容器分別安裝了 Python 3.10 和 3.11,並查看它們在一組基準測試中的比較。
在其中使用了pyperformance 包來完成這項工作,這個包會幫助開發者完成繁重的基準測試工作。
總結的數據,按平均數值來計算,Python 3.11 比 Python 3.10 快了 14%。3.11 新版本在某些基準測試上稍微慢了一點,但在大多數基準上,速度提高了 64%。
以下是在有着 10 核 CPU 的 M1 Pro MacBook Pro 16 上運行的基準測試。每個 Python 版本都安裝在 Docker 中,它使用 5 個邏輯 CPU 內核。
以下是不同包的運行數據:

目前Python 3.11 的正式版還未正式發布,需要等待一個完全穩定的版本,目前測試的僅是一個候選版本,也許正式版本發布後兩者之間的差距會更大。
相關報道:提速25%!CPython 3.11 來了
文 | 羅奇奇,出品 | OSC開源社區(ID:oschina2013)在退休又復出加入微軟的 Faster CPython 團隊後, Python 之父 Guido van Rossum 在 2021 年 Python 語言峰會上放下狠話,稱團隊將在 Python 3.11 版本中實現至少提速 1 倍的進展。

而在今年的 Python 語言峰會上,Guido 和團隊搭檔 Mark Shannon 匯報了最新的進展:對比 3.10 版本,CPython 3.11 的提速在10 - 60% 之間,具體速度取決於代碼規模和工作領域等條件。當使用 pyperformance 基準套件測量在 Ubuntu Linux 上使用 GCC 編譯時, CPython 3.11 平均比 CPython 3.10快 25% 。

CPython 3.11 的性能改進主要集中在更快的啟動和更快的運行時,這些優化大部分來自於 PEP 659 :自適應解釋器,它運作思路跟 JIT 有點相似,都是識別熱點代碼,但自適應解釋器的工作範圍無法脫離字節碼。目前 PEP 659 提案的工作基本完成,但 for 循環和二進制操作的動態優化仍有待完成。在提速 25% 的同時,Python 3.11 仍有一些需要改善的地方,比如 Python 在 3.11 中的內存消耗與 3.10 中的基本相同。此外還需關注 C 擴展的問題:CPython 與 C 的簡單接口是主要優勢,而與 C 擴展的不兼容性則是一大槽點。而 Faster CPython 團隊在 CPython 3.11 中所做的優化工作在很大程度上忽略了擴展模塊的問題,對此,團隊領導者 Shannon 表示,團隊正在開闢將低級函數 API 暴露給虛擬機的可能性,以儘可能地減少 Python 代碼和 C 代碼。至於飽受期待的JIT 編譯器,Shannon 表示實現 JIT 的第一步是實現一個跟蹤解釋器,但目前還有太多需要關注的項目,引入 JIT 編譯器的工作還有一段路要走,「最早可能要到 3.13 才能到達」。(順便說一下,Shannon 一直對 CPython 是否真的需要引入 JIT 持懷疑態度。)有意思的是,昨天我們報道了開發者 Sam Gross 的新提案:完全移除 CPython 解釋器的 GIL-全局解釋器鎖。這個提案和 Faster CPython 團隊的工作將以截然不同的方式加速多線程 Python 代碼,但兩者又可能產生一些衝突,畢竟 Faster CPython 已實施的優化,很大一部分都基於 GIL 仍存在的前提。註:在去年的核心開發者 sprint 會議上,核心開發者們跟 Sam Gross 對 nogil 項目做了一次深入研討,回答了大家較為關注的諸多問題。具體的會議紀要,可查看這篇文章——Python 官方研討會:徹底移除 GIL 真的可行麼?
(以上僅為部分展示,全部資料的話可留言 1 )