Erlang JSON 库:序列化性能?

发布于 2024-08-09 17:10:23 字数 647 浏览 4 评论 0 原文

Erlang 有许多可用的 JSON 库,但我不清楚哪些具有最佳性能特征(其次是易用性),特别是对于 erlang-to-json 序列化。

我的用例需要 JSON 解析和序列化,但 Erlang 代码可能会产生比接收输入至少多两个数量级的 JSON 输出(即序列化)。

作为参考,我知道的库包括以下内容(可能还有其他我还没有找到):

There are a number of JSON libraries available for Erlang, and it's not clear to me which have the best performance characteristics (and, secondarily, ease of use), especially for erlang-to-json serialization.

My use case requires both JSON parsing and serialization, but the Erlang code will probably be producing at least two orders of magnitude more JSON output (i.e. serialization) than it will receive input.

For reference, the libraries I know of include the following (and there may be others I haven't found):

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

德意的啸 2024-08-16 17:10:23

我使用 rfc4627.erl (我偶然发现了它,性能并不是问题)

但是,我确实希望不同的本机 erlang 库也能表现得同样好。他们分享想法(正如代码注释中所见证的那样)。 AFAIK mochijsonrfc4627 共享相同的源 erlang 格式。

eep018 是 C,并且它正在努力实现... hrm ... eep-0018term_to_json 本机编码器可能包含在Erlang 的未来版本。从未尝试过并且似乎没有积极维护。

我的最终建议是使用 mochiweb 的 mochijson(2)。它是事实上的标准,并由 CouchDB 和 Facebook 等积极维护和使用。

至于在 mochijsonmochijson2 之间进行选择,这个 可能对你有帮助。

I use rfc4627.erl (I stumbled upon it, and performance has not been an issue)

However, I do expect the different native erlang libraries to perform similarly well. They share ideas (as witnessed in the code comments). AFAIK mochijson and rfc4627 share the same source erlang format.

eep018 is C, and as it is striving to implement ... hrm ... eep-0018, the term_to_json native encoder that might be included in a future version of Erlang. Never tried it and doesn't seem actively maintained.

My final recommendation is go with mochiweb's mochijson(2). It is the de facto standard and actively maintained, used by, among others, CouchDB and Facebook.

As for choosing between mochijson and mochijson2, this might help you.

老子叫无熙 2024-08-16 17:10:23

我最近一直在使用 jsonerl 。它基于 mochijson2,使用起来更加简单和直观。

I've been using jsonerl lately. It's based on mochijson2 and is much more easy and intuitive to use.

挽容 2024-08-16 17:10:23

尝试 https://github.com/si14/erl_json_test erlang json 基准测试。它包括以下基准:

  • List item

  • JSONX

  • Jiffy

  • Mochijson2

  • JSX

Try https://github.com/si14/erl_json_test erlang json benchmarks. It included benchmarks for:

  • List item

  • JSONX

  • Jiffy

  • Mochijson2

  • JSX

输什么也不输骨气 2024-08-16 17:10:23

不过,希望这个答案不会受到欢迎:

我也研究了一个项目的 JSON 解析和序列化。我必须并行处理大量数据,所以 Erlang 听起来很棒!但其中很多都是以 JSON 数据形式处理字符串,这就是事情变得糟糕的地方。

你可能知道 Erlang 中的字符串是完整的字符列表。与大多数语言中的字符串不同(一个字符“大约”一个字节),Erlang 中的每个字符都由一个完整的 32 位整数表示!所以,你的字符串已经很大了。

因为它是一个列表,所以访问字符串的给定元素的时间复杂度为 O(N),而不是您在 Chars 数组中所期望的 O(1)。而且,由于字符串在 Erlang 中是不可变的,简单的串联最终可能会是一个非常缓慢的过程。最后我意识到我只是想使用错误的语言。

您很可能已经知道所有这些事情,但我认为将其作为答案留给将来可能到达您职位的其他人是有用的。

Hopefully this answer won't be ill-received, however:

I too looked into JSON parsing and serialization for a project. I had to process a lot of data in parallel, so Erlang sounded great! But a lot of that was dealing strings in the form of JSON data, and that's where things went sour.

As you probably know strings in Erlang are full fledged lists of characters. Unlike strings in most languages (a char is "about" a byte), each character in Erlang is represented by a whole 32-bit integer! So, already your strings are quite large.

Because it's a list, access to a given element of the string is O(N) instead of O(1) as you'd expected in an array of Chars. And, because strings are immutable in Erlang simple concatenation can end up being a very slow process. In the end I realized I was simply trying to use the wrong language.

In all likelihood you already know all of these things, but I felt it was useful to leave this as an answer for others who may at arrive at your post in the future.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文