• 当Python开发遇到JSON编码或解码瓶颈
  • 发布于 2个月前
  • 179 热度
    0 评论
使用JSON越多, 你就越有可能遇到JSON编码或解码瓶颈。Python的内置库也不错, 但是还有多个更快的JSON库可用: 如何选择使用哪一个呢?

事实是,没有一个正确的答案,没有一个最快的JSON库来超越其他所有库:
一个“快速的JSON库”对不同的人意味着不同的东西,因为它们的使用模式不同。
速度并不是一切——你可能还会关心其他一些事情,比如安全性和可定制性。

因此,为了帮助你根据需要选择最快的JSON库,我想在这里分享一下我为Python选择一个快速JSON库所经历的过程。你可以使用这个过程来选择最适合你的特殊需要的库:
确保确实有问题需要用到JSON库来解决。
定义基准。
根据附加要求来过滤。
对剩下的候选者进行基准测试。

步骤#1: 你确实需要一个新的JSON 库吗?

使用JSON并不意味着它就是一个相关的瓶颈。在考虑使用哪个JSON库之前,你需要一些证据来表明Python的内置JSON库确实在特定应用程序中存在问题。

在我的例子中,我从我的原因日志库Eliot(causal logging library Eliot)的基准测试中学到了这一点,它表明JSON编码占用了大约25%的用于生成消息的CPU时间。我能得到的最大加速是比原先运行快33%(如果JSON编码时间变为零),但那是一个足够大的时间块,使用最快的JSON库会让这个时间块减小到最低。
步骤 #2: 定义基准

如果你查看各种JSON库的基准页面,你会发现它们都会讨论如何处理各种不同的消息。然而,这些消息并不一定与你的使用相关。其他人会经常测量非常大型消息,但在我的例子中,我只关心小型消息。

所以你想要提出一些符合你的特定使用模式的措施:
1.你关心编码、解码,还是两者都关心?
2.你使用的是小型消息还是大型消息?
3.典型的消息是什么样的?

在我的例子中,我主要关心的是编码小型消息,即由Eliot生成的日志消息的特定结构。基于一些真实的日志,我整理出了以下示例消息:
{
    "timestamp": 1556283673.1523004,
    "task_uuid": "0ed1a1c3-050c-4fb9-9426-a7e72d0acfc7",
    "task_level": [1, 2, 1],
    "action_status": "started",
    "action_type": "main",
    "key": "value",
    "another_key": 123,
    "and_another": ["a", "b"],
}

步骤 #3: 根据附加要求来过滤

性能并不是一切——你可能还会关心其他一些事情。在我的例子中:
1.安全性/抗崩溃性:日志消息可以包含来自不可信源的数据。如果JSON编码器在不良数据上崩溃,这对可靠性或安全性都不好。
2.自定义编码: Eliot支持自定义JSON编码,因此您可以序列化其他类型的Python对象。有些JSON库支持这一点,有些则不支持。
3.跨平台: 运行在Linux、macOS和Windows上。
4.维护: 我不想依赖一个没有得到积极支持的库。

我考虑的库有orjson、rapidjson、ujson和hyperjson。

我根据上面的标准过滤掉了其中的一些:
1.ujson有很多关于崩溃的bug,即使那些已经修复的崩溃也并不总是可用,因为自2016年以来就没有再发布过新版本。

2.hyperjson只有针对macOS的包,而且总体看起来也相当不成熟。


步骤 #4: 基准测试

最后的两个竞争者是rapidjson和orjson。我运行了以下基准测试:
import time
import json
import orjson
import rapidjson

m = {
    "timestamp": 1556283673.1523004,
    "task_uuid": "0ed1a1c3-050c-4fb9-9426-a7e72d0acfc7",
    "task_level": [1, 2, 1],
    "action_status": "started",
    "action_type": "main",
    "key": "value",
    "another_key": 123,
    "and_another": ["a", "b"],
}

def benchmark(name, dumps):
    start = time.time()
    for i in range(1000000):
        dumps(m)
    print(name, time.time() - start)

benchmark("Python", json.dumps)
# orjson only outputs bytes, but often we need unicode:
benchmark("orjson", lambda s: str(orjson.dumps(s), "utf-8"))
benchmark("rapidjson", rapidjson.dumps)

结果如下:
$ python jsonperf.py 
Python 4.829106330871582
orjson 1.0466396808624268
rapidjson 2.1441543102264404

即使需要额外的Unicode解码,orjson也是最快的(对于这个特定的基准测试!)。

与往常一样,我也需要权衡。orjson的用户比rapidjson要少(比较orjson PyPI stats和rapidjson PyPI stats),并且它也没有Conda包,所以我必须自己为Conda-forge对它进行打包。但是,它确实要快得多。

你的地盘你做主

你应该使用orjson吗? 不一定。你可能有不同的要求,你的基准测试也可能不同——例如,你可能需要解码大型文件。

关键点是过程: 找出你的特定要求,比如性能以及其他方面,然后选择最适合你的需求的库。
用户评论