Using Jsonrs instead of Jason in Phoenix

Today i found this json plugin that use rustler

What do you think about it?
Do you suggest it instead jason in phoenix?


I do wish it included the benchmarking code. It’s showing more iterations for Poison than Jason which doesn’t seem right.

Also, any benchmark on JSON needs to include many different sizes, including small ones. Most JSON APIs send and receive payloads much, much smaller than 80mb, I’m curious about how the comparison looks with a payload the size of 1k.


It’s an unquestionable truth that any [well-written] Rust-based JSON parser will perform better than any interpreted language (like Erlang / Elixir).

But you do have to take other things into account, like native compilation during CI/CD which can dramatically slow your builds – which can introduce irritation and needless waiting time before approving PRs, for example.

Furthermore, as @benwilson512 suggested, it’s very likely that for your average request (1k - 4k worth of JSON) the differences between Elixir and Rust JSON parsers aren’t likely to be big (or even any).

So overall: no, it’s definitely not worth it to introduce native compilation dependency unless your project is parsing megabytes of JSON on each request.


In other words:

Profile, then optimise. Never other way around.


Can confirm. Tested in prod.


As the author of Jsonrs, I’ll echo the same sentiments that others in this thread have. I suggest using Jsonrs if it satisfies a need you have, and not using it otherwise.

At the company I worked for when I wrote Jsonrs, we were having trouble with our application instances running out of memory and getting OOM-killed when Jason or Poison would generate several gigabytes of uncollected garbage while trying to encode ~80MB of json. Jsonrs was born primarily to address that memory issue, and the extra speed at that scale was a bonus.

The advantages of using Jsonrs diminish as the json you’re typically encoding gets smaller, and there is certainly a lot of friction in including a Rust NIF in your build pipeline if you don’t already have others. It will definitely impact your build times if you aren’t caching dependencies between builds. By and large, if Jason meets your needs, you should probably just stick with it.

It’s just Jason’s benchmark with some of the encoders removed and Jsonrs added in. I’m not overly keen on plagiarizing existing benchmark scripts or committing huge json blobs to git, but I should probably drop a note somewhere pointing to that.