6個(gè)庫(kù)讓你寫出同步代碼跑出異步速度摘要性能優(yōu)化的新思路很長(zhǎng)時(shí)間以來(lái), 在我們談及性能之際, 有一個(gè)無(wú)法避開的話題便是多線程。面對(duì)數(shù)據(jù)處理、網(wǎng)絡(luò)爬取或者I/O密集型任務(wù)所存在的性能瓶頸, 好多開發(fā)者會(huì)下意識(shí)地尋求多線程方案, 指望借助并發(fā)去加快腳本運(yùn)行。然而, 存在的全局解釋器鎖GIL以及由此產(chǎn)生的上下文切換開銷, 常常致使多線程代碼不但沒有帶來(lái)預(yù)期中的性能提高, 反而有可能成為性能的“瓶頸”或者“拖累”。可是, 時(shí)代已然發(fā)生了變化, 當(dāng)下, 一些具革命性的庫(kù)正起著改變這一情形的作用。存在這樣一些庫(kù), 它們于底層展開了深度優(yōu)化工作, 優(yōu)化所利用的常常是憑借Rust、C語(yǔ)言來(lái)達(dá)成, 或者是運(yùn)用高效的異步I/O模型這種方式, 進(jìn)而致使它們?cè)膱?zhí)行速度快到了足以將手動(dòng)管理并發(fā)的必要性給抵消掉的程度。這些庫(kù)讓開發(fā)者編寫呈現(xiàn)直觀、同步特點(diǎn)的代碼, 然而卻能夠以如同呈現(xiàn)“暴風(fēng)雪”般的速度去處理數(shù)據(jù)。這兒會(huì)深度講述那六個(gè)致使作者徹底摒棄多線程的庫(kù)或者工具, 并且闡釋它們?cè)鯓咏栌傻讓拥臋C(jī)制達(dá)成性能的迅猛提升, 給你鋪就一條在不增添代碼繁雜程度的狀況下, 極大提高性能的全新道路句號(hào)。一、性能瓶頸的傳統(tǒng)解法與新挑戰(zhàn)多線程的困境于深入知悉這般高性能庫(kù)之前, 我們首先得弄明白為何其中的多線程并非那能解決一切問(wèn)題, 的藥。的性能硬傷GIL與上下文切換的性能并不以“原始速度”著稱。這主要?dú)w咎于兩個(gè)核心問(wèn)題一個(gè)名為全局解釋器鎖的裝置也就是 GIL, 它作出這種確保, 即在任意給定的時(shí)刻之內(nèi), 僅僅會(huì)有單獨(dú)的一個(gè)線程能夠于虛擬機(jī)里執(zhí)行字節(jié)碼。而這所蘊(yùn)含的意義在于, 針對(duì)于那種CPU屬于密集型的任務(wù)而言, 多線程是沒有辦法去借助多核所具備的優(yōu)勢(shì)的, 相反地, 會(huì)由于GIL所帶來(lái)的限制以及線程之間非常頻繁的切換也就是上下文切換所產(chǎn)生的開銷, 從而致使速度被拖慢。切換上下文所產(chǎn)生的開銷: 即便置身于I/O密集型任務(wù)里, 多線程盡管能夠起到作用緣由在于當(dāng)一個(gè)線程正等候I/O之際, GIL能夠釋放予另一個(gè)線程, 然而管理線程、同步數(shù)據(jù)像是鎖、信號(hào)量以及線程自身的切換均會(huì)造成不容小覷的開銷。以往的時(shí)候, 在腳本運(yùn)行遲緩之際, 我們時(shí)常本能地去求助多線程, 以此來(lái)應(yīng)對(duì)數(shù)據(jù)處置、網(wǎng)頁(yè)信息采集或者輸入輸出密集型工作。然而, 就如同作者所領(lǐng)悟到的那種具有革新性質(zhì)的知識(shí)表明: 有的情況下, 你壓根兒不一定要借助線程去達(dá)成速度提升。新時(shí)代的解決方案庫(kù)內(nèi)嵌的并行優(yōu)化高性能庫(kù)問(wèn)世了, 實(shí)際上是這般模樣, 把并發(fā)方面存在的復(fù)雜性, 從應(yīng)用領(lǐng)域這一層面, 推到了庫(kù)的基底之處。它們借助下面這些方式達(dá)成令人驚嘆的速度:下面我們將逐一介紹這六個(gè)“高性能黑科技”。二、數(shù)據(jù)分析的“一級(jí)方程式”告別的慢速困境對(duì)于那些從事處理大規(guī)模數(shù)據(jù)集工作的開發(fā)者而言, 這屬于標(biāo)準(zhǔn)配置, 然而它的性能瓶頸正愈發(fā)明顯地呈現(xiàn)出來(lái)。它的出現(xiàn), 就好像是從“家庭轎車升級(jí)至F1賽車”這種情況。它是一款依據(jù)Rust構(gòu)建而成的庫(kù), 專門針對(duì)性能以及并行化進(jìn)行了優(yōu)化。它的API和別的類似, 極為便于上手, 不過(guò)它在無(wú)需手動(dòng)管理線程的情況下就能達(dá)成極高的速度。為何如此之快的速度優(yōu)勢(shì)來(lái)源于其底層設(shè)計(jì)和實(shí)現(xiàn)機(jī)制簡(jiǎn)單示例自動(dòng)并行化操作使用時(shí)開發(fā)者只需編寫簡(jiǎn)潔的鏈?zhǔn)酵酱a如下所示import polars as pl df pl.read_csv(sales.csv) result ( df.lazy() .filter(pl.col(region) Europe) .group_by(product) .agg(pl.col(revenue).sum()) .collect() )這段代碼執(zhí)行的速度, 相較于多線程而言會(huì)更快, 這是由于它于內(nèi)部自動(dòng)地對(duì)所有操作進(jìn)行了并行化處理。從而開發(fā)者獲取到了高性能, 然而卻并不需要去管理任何線程。應(yīng)用場(chǎng)景三, JSON解析里有個(gè)“閃電俠”, 它是內(nèi)置JSON模塊, 存在性能短板。要是你曾經(jīng)處理過(guò)那種規(guī)模很大的JSON文件, 或者做過(guò)數(shù)量眾多的JSON序列化以及反序列化相關(guān)操作, 那你肯定特別清楚內(nèi)置的json模塊到底有多遲緩。它是專為這個(gè)而產(chǎn)生的, 它是一個(gè)借助Rust予以實(shí)現(xiàn)的JSON庫(kù), 它的性能相較于內(nèi)置的json模塊或者ujson要快上2至10倍。極速背后的秘密通過(guò)以下優(yōu)化實(shí)現(xiàn)了性能的碾壓簡(jiǎn)單示例毫秒級(jí)完成大型JSON解析曾需要多線程來(lái)解析的那種龐大的JSON文件, 眼下借助其一實(shí)現(xiàn)了在毫秒級(jí)能夠同步達(dá)成做完:import orjson data {user: Aashish, score: 99} serialized orjson.dumps(data) deserialized orjson.loads(serialized)異步I/O的“增壓器”, 其應(yīng)用場(chǎng)景的第四個(gè)方面, 是默認(rèn)事件循環(huán)存在性能局限。面向I/O密集型任務(wù)而言的庫(kù), 以及其內(nèi)部所設(shè)置的事件循環(huán), 是一種極好且相當(dāng)優(yōu)異卓越的解決辦法。然而, 我們?cè)灸軌蚴┱谷_的更大潛力, 卻是可以做得更棒、更為精巧妥善周全妥善, 以超越這一情況的。是一個(gè)替代品, 可用于事件循環(huán), 它基于libuv構(gòu)建, libuv它是Node.js所依賴的同一個(gè)C語(yǔ)言庫(kù)。的性能提升效果作者把它替換進(jìn)而置于后端之時(shí), 響應(yīng)時(shí)間出現(xiàn)了下降, 降至原來(lái)的40%到50%這個(gè)幅度范圍, 整個(gè)此過(guò)程, 既不需要增添線程, 又不需要額外的代碼。為何能大幅提速簡(jiǎn)單示例一行代碼實(shí)現(xiàn)性能飛躍只需一行代碼, 就能把默認(rèn)循環(huán)替換成, 使你的異步代碼立刻“裝上超速引擎”:import asyncio import uvloop asyncio.set_event_loop_policy(uvloop.EventLoopPolicy())應(yīng)用場(chǎng)景五, 存在一種無(wú)需對(duì)原代碼做修改的“加速魔法”, 即為PyPy運(yùn)行時(shí), 并不去更換代碼, 而僅僅是更換其運(yùn)行的環(huán)境。偶爾, 增強(qiáng)性能的最終訣竅并非更換一個(gè)庫(kù), 而是更換一個(gè)運(yùn)行之時(shí)的環(huán)境。存在一種即時(shí)編譯JIT的實(shí)現(xiàn), 此為PyPy。對(duì)于CPU密集類型的代碼而言, 它可促成兩倍至四倍的速度提升, 有可能還遠(yuǎn)超這個(gè)范圍 , 還有更多。PyPy的加速機(jī)制適用條件要是你的代碼屬于純粹編寫, 同時(shí)對(duì)有關(guān)C語(yǔ)言擴(kuò)展的依賴程度不高, 那么PyPy會(huì)明顯戰(zhàn)勝標(biāo)準(zhǔn)的運(yùn)行時(shí)。簡(jiǎn)單示例直接運(yùn)行獲得速度只需用pypy3命令替換來(lái)運(yùn)行你現(xiàn)有的腳本pypy3 my_script.py就這么簡(jiǎn)單無(wú)需多線程無(wú)需異步只有速度。場(chǎng)景六, PyPy的應(yīng)用講的是函數(shù)級(jí)的“原生指令”, 它是Numba科學(xué)計(jì)算時(shí)性能方面至關(guān)重要的工具。Numba是個(gè)堪稱“作弊神器”之物件, 它具備把函數(shù)編譯為經(jīng)優(yōu)化后機(jī)器碼之本事。僅僅添加一個(gè)裝飾器, 開發(fā)者便能使得字節(jié)碼, 在LLVM那樣一種流行的編譯器基礎(chǔ)設(shè)施之下, 被編譯成為達(dá)到優(yōu)化目的和滿足需要條件的那種運(yùn)行原本編碼指令。這里的LLVM便是流行的被稱為編譯器基礎(chǔ)設(shè)施的東西。Numba的加速原理簡(jiǎn)單示例一個(gè)裝飾器實(shí)現(xiàn)數(shù)十倍加速只需在函數(shù)前添加njit裝飾器from numba import njit import numpy as np njit def compute(arr): total 0 for x in arr: total x ** 2 return total print(compute(np.arange(1_000_000)))相較純的情況而言, 這段代碼的運(yùn)行速度要比僅僅是純的那種快上數(shù)十倍, 同樣地此代碼的運(yùn)行過(guò)程中, 并不需要線程, 也不需要異步, 僅僅存在著一個(gè)裝飾器。Numba的應(yīng)用場(chǎng)景七, 分布式計(jì)算的那種“無(wú)感擴(kuò)展”, Ray告別了手動(dòng)管理并發(fā)會(huì)有的痛苦。Ray是這樣一個(gè)庫(kù), 針對(duì)分布式計(jì)算專門得到布置, 然而就算停于單打獨(dú)斗的機(jī)器條件之下, 它依舊能夠供應(yīng)出超乎尋常等級(jí)的卓有成效功效結(jié)果。Ray借助直觀的API, 把底層的線程隱藏起來(lái), 把底層的進(jìn)程進(jìn)行抽象, 甚至還把底層的分布式節(jié)點(diǎn)給藏起來(lái)屏蔽掉。Ray的效率優(yōu)勢(shì)Ray讓開發(fā)者能夠去定義actor也就是持久化對(duì)象, 還能定義task即無(wú)狀態(tài)函數(shù), 這些任務(wù)以及actor會(huì)自動(dòng)在多核環(huán)境下, 甚至是在多臺(tái)機(jī)器上展開擴(kuò)展以及調(diào)度工作, 它給出了一種取代手動(dòng)處理并發(fā)的辦法。簡(jiǎn)單示例自動(dòng)并行任務(wù)執(zhí)行會(huì)自動(dòng)并行執(zhí)行所有任務(wù)的是下面的這段代碼片段, 開發(fā)者對(duì)于任何線程邏輯、鎖或者同步問(wèn)題都不需要去關(guān)心。import ray ray.init() ray.remote def square(x): return x * x results ray.get([square.remote(i) for i in range(1_000)])Ray的應(yīng)用場(chǎng)景八、為什么是時(shí)候放棄手動(dòng)多線程了多線程, 于理論層面而言, 具備很強(qiáng)的特性, 然而, 在實(shí)際開展操作期間, 卻給開發(fā)環(huán)節(jié)以及維護(hù)方面帶來(lái)了諸多的負(fù)擔(dān):有競(jìng)態(tài)條件, 也就是Race, 還有死鎖, 其調(diào)試過(guò)程復(fù)雜, 存在GIL的限制, 并且有著高昂的維護(hù)成本。猶如本文所闡述的那般, 現(xiàn)代的庫(kù), 尤其是那些借助Rust、C或者異步I/O的庫(kù), 把并發(fā)轉(zhuǎn)變成了隱式的狀態(tài)。它們將性能的提升推進(jìn)到了庫(kù)的內(nèi)部實(shí)現(xiàn)層面這兒, 使得開發(fā)者能夠?qū)Ｗ⒂跇I(yè)務(wù)邏輯部分, 而并非同步機(jī)制方面。話簡(jiǎn)短來(lái)講: 假設(shè)庫(kù)能夠更為幫你去處理并行化方面, 那么你就不存在再借著自己動(dòng)用手腳, 手去編寫并行代碼的這種必要性。進(jìn)階組合與協(xié)同如果你想將性能提升到更高的層次可以將這些庫(kù)進(jìn)行組合當(dāng), 你的技術(shù)棧, 能夠, 與性能, 協(xié)同, 而不是, 對(duì)抗性能時(shí), 多線程, 就會(huì), 徹底, 淪為, 最后的, 選擇, 而不是, 必需品。九、總結(jié)速度與簡(jiǎn)潔性并行不悖曾經(jīng), 于往昔歲月之際, 若去追尋性能, 常常就意味著要去接納復(fù)雜性, 諸如線程, 還有鎖、隊(duì)列這一類, 以及形形色色會(huì)讓人倍感頭疼的諸多問(wèn)題。眼下恰當(dāng)?shù)墓ぞ吣軌蛴谀缓筇婺氵_(dá)成全部并發(fā)事項(xiàng)。諸如PyPy、Numba以及Ray等這六個(gè)庫(kù)證明確實(shí)可以一并兼具優(yōu)雅的代碼構(gòu)建以及宛如閃電般快捷的速度, 與此同時(shí)也無(wú)需去犧牲開發(fā)者的那種幸福感。那么, 下次哪時(shí)你發(fā)覺腳本運(yùn)轉(zhuǎn)遲緩, 請(qǐng)莫再慣常性抓取線程咯, 而是要去覓尋出一個(gè)更為聰慧、更具優(yōu)化性的庫(kù), 。并非是同時(shí)開展諸多事情, 方才稱得上具備真正的速度, 而是唯獨(dú)把一件事情, 做到極為卓越出色的那種程度, 稱得上真正有速度, 這才是關(guān)鍵所在。