使用JSON越多，遇到JSON编码和解码瓶颈的可能性就越大。 Python的内置库也可以，但有多个更快的JSON库。 在：上怎么选择使用哪个？

事实上，没有正确的答案。 没有速度最快的JSON库超过其他所有库：

“高速的JSON库”由于使用模式不同，因此意味着因人而异。 速度不都是——。 你可能也对其他事情感兴趣，比如安全性和定制性。 因此，为了根据需要选择最快的JSON库，在此我想共享为Python选择高速JSON库的过程。 使用此过程可以选择最适合您特殊需要的库：

验证是否需要使用JSON库解决问题。 定义标准。 根据附加要求进行过滤。 对剩下的候选人进行基准测试。 使用

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

JSON并不意味着它是相关的瓶颈。 在考虑使用哪个JSON库之前，需要有证据表明Python的内置JSON库在特定的APP上有问题。

在我的例子中，我从我的原因日志库Eliot (causallogginglibraryeliot )的基准中学习了这个。 这表明JSON编码占用了约25%的CPU时间来生成消息。 我能得到的最大加速是，在JSON编码时间为零的情况下，比原来的执行速度快33%，但是它是足够大的时间块，使用最快的JSON库，可以将这个时间块抑制到最小。

步骤 #2: 定义基准

查看各种JSON库的基准页面，您会发现正在考虑如何处理各种消息。 但是，这些消息并不一定与你的使用有关。 别人经常测量非常大的新闻，但我的例子中只关心小新闻。

所以，我想建议符合你特定使用模式的措施：

你对编码、解码还是两者都感兴趣？ 你用的是小型新闻还是大型新闻？ 典型的新闻是什么样的？ 在我的示例中，我对小消息进行编码感兴趣，小消息是主要由Eliot生成的日志消息的特定结构。 根据一些实际日志，整理了以下示例消息：

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

的性能不是所有的——。 你可能也对其他的事情感兴趣。 在我的例子中是：

安全性/抗崩溃性：日志消息可以包含来自源的数据。 如果JSON编码器因不良数据而崩溃，则可靠性和安全性会下降。 由于自定义代码： Eliot支持自定义JSON代码，因此可以序列化其他类型的Python对象。 一些JSON库支持此功能，另一些不支持此功能。 跨平台：在Linux、macOS和Windows上运行。 要维持：我不想依赖不积极支持的库。 我想的库有orjson、rapidjson、ujson和hyperjson。

根据上面的标准过滤了：的一部分

ujson中有许多碰撞错误，即使是修复的碰撞也不一定总是可用。 因为2016年以后没有发布新版本。 hyperjson只有面向macOS的软件包，整体看起来也相当不成熟。

步骤 #4: 基准测试

的最后一个竞争对手是rapidjson和orjson。 我执行了以下基准测试：

结果是以下：

即使需要额外的Unicode解码，orjson也是最快的(请参见。

和往常一样，我也需要权衡一下。 orjson的用户少于rapidjson，将OR JSon PyPi状态与RAPID JSon PyPI状态进行比较。 另外，由于没有Conda软件包，所以必须自己为Conda-forge打包。 但那确实快得多。

你的地盘由你决定

我应该用orjson吗？ 不，不是。 可能有不同的要求，基准也可能与——不同。 例如，可能需要对较大的文件进行解码。

重要的是，流程：确定特定要求(如性能)，然后选择最适合您需要的库。

译文： 3359 python speed.com/articles/faster-JSON-library /译者：浣熊君() ) ) ) ) ) ) ) ) ) ) ) ) ) )。