使用JSON越多, 你就越有可能遇到JSON編碼或解碼瓶頸。Python的內(nèi)置庫(kù)也不錯(cuò), 但是還有多個(gè)更快的JSON庫(kù)可用: 如何選擇使用哪一個(gè)呢?

事實(shí)是，沒(méi)有一個(gè)正確的答案，沒(méi)有一個(gè)最快的JSON庫(kù)來(lái)超越其他所有庫(kù):

一個(gè)“快速的JSON庫(kù)”對(duì)不同的人意味著不同的東西，因?yàn)樗鼈兊氖褂媚Ｊ讲煌?/p>

速度并不是一切——你可能還會(huì)關(guān)心其他一些事情，比如安全性和可定制性。

因此，為了幫助你根據(jù)需要選擇最快的JSON庫(kù)，我想在這里分享一下我為Python選擇一個(gè)快速JSON庫(kù)所經(jīng)歷的過(guò)程。你可以使用這個(gè)過(guò)程來(lái)選擇最適合你的特殊需要的庫(kù):

確保確實(shí)有問(wèn)題需要用到JSON庫(kù)來(lái)解決。

定義基準(zhǔn)。

根據(jù)附加要求來(lái)過(guò)濾。

對(duì)剩下的候選者進(jìn)行基準(zhǔn)測(cè)試。

步驟1:?你確實(shí)需要一個(gè)新的JSON 庫(kù)嗎?

使用JSON并不意味著它就是一個(gè)相關(guān)的瓶頸。在考慮使用哪個(gè)JSON庫(kù)之前，你需要一些證據(jù)來(lái)表明Python的內(nèi)置JSON庫(kù)確實(shí)在特定應(yīng)用程序中存在問(wèn)題。

在我的例子中，我從我的原因日志庫(kù)Eliot(causal logging library Eliot)的基準(zhǔn)測(cè)試中學(xué)到了這一點(diǎn)，它表明JSON編碼占用了大約25%的用于生成消息的CPU時(shí)間。我能得到的最大加速是比原先運(yùn)行快33%(如果JSON編碼時(shí)間變?yōu)榱?，但那是一個(gè)足夠大的時(shí)間塊，使用最快的JSON庫(kù)會(huì)讓這個(gè)時(shí)間塊減小到最低。

步驟 2:?定義基準(zhǔn)

如果你查看各種JSON庫(kù)的基準(zhǔn)頁(yè)面，你會(huì)發(fā)現(xiàn)它們都會(huì)討論如何處理各種不同的消息。然而，這些消息并不一定與你的使用相關(guān)。其他人會(huì)經(jīng)常測(cè)量非常大型消息，但在我的例子中，我只關(guān)心小型消息。

所以你想要提出一些符合你的特定使用模式的措施:

你關(guān)心編碼、解碼，還是兩者都關(guān)心?

你使用的是小型消息還是大型消息?

典型的消息是什么樣的?

在我的例子中，我主要關(guān)心的是編碼小型消息，即由Eliot生成的日志消息的特定結(jié)構(gòu)?；谝恍┱鎸?shí)的日志，我整理出了以下示例消息:

步驟 3:?根據(jù)附加要求來(lái)過(guò)濾

性能并不是一切——你可能還會(huì)關(guān)心其他一些事情。在我的例子中:

安全性/抗崩潰性:日志消息可以包含來(lái)自不可信源的數(shù)據(jù)。如果JSON編碼器在不良數(shù)據(jù)上崩潰，這對(duì)可靠性或安全性都不好。

自定義編碼: Eliot支持自定義JSON編碼，因此您可以序列化其他類(lèi)型的Python對(duì)象。有些JSON庫(kù)支持這一點(diǎn)，有些則不支持。

跨平臺(tái): 運(yùn)行在Linux、macOS和Windows上。

維護(hù): 我不想依賴(lài)一個(gè)沒(méi)有得到積極支持的庫(kù)。

我考慮的庫(kù)有orjson、rapidjson、ujson和hyperjson。

我根據(jù)上面的標(biāo)準(zhǔn)過(guò)濾掉了其中的一些:

ujson有很多關(guān)于崩潰的bug，即使那些已經(jīng)修復(fù)的崩潰也并不總是可用，因?yàn)樽?016年以來(lái)就沒(méi)有再發(fā)布過(guò)新版本。

hyperjson只有針對(duì)macOS的包，而且總體看起來(lái)也相當(dāng)不成熟。

步驟 4:?基準(zhǔn)測(cè)試

最后的兩個(gè)競(jìng)爭(zhēng)者是rapidjson和orjson。我運(yùn)行了以下基準(zhǔn)測(cè)試:

結(jié)果如下:

即使需要額外的Unicode解碼，orjson也是最快的(對(duì)于這個(gè)特定的基準(zhǔn)測(cè)試!)。

與往常一樣，我也需要權(quán)衡。orjson的用戶(hù)比rapidjson要少(比較orjson PyPI stats和rapidjson PyPI stats)，并且它也沒(méi)有Conda包，所以我必須自己為Conda-forge對(duì)它進(jìn)行打包。但是，它確實(shí)要快得多。

需求為大

你應(yīng)該使用orjson嗎? 不一定。你可能有不同的要求，你的基準(zhǔn)測(cè)試也可能不同——例如，你可能需要解碼大型文件。

關(guān)鍵點(diǎn)是過(guò)程: 找出你的特定要求，比如性能以及其他方面，然后選擇最適合你的需求的庫(kù)。

聲明：文章來(lái)源于網(wǎng)絡(luò)，侵刪！