benhaney

benhaney

Jsonrs is a JSON library like Jason or Poison, but it’s faster and uses much less memory. This is thanks to the core of it being a Rust NIF leveraging Rust’s excellent serialization framework, serde.

Recently, Jsonrs started using rustler_precompiled, so you no longer need an entire Rust toolchain in your build pipeline in order to start using Jsonrs in your project! This was a significant blocker for a lot of people in adopting Jsonrs before, so I’m excited that there’s such a good solution to it now, and I hope it breathes some life back into Jsonrs.

Since the main purpose of Jsonrs is performance, I’ll talk a little about that here so you can evaluate if it’s worthwhile for your use-case:

  • The primary benefit of Jsonrs, and what it was originally built to solve, is reducing memory usage when encoding large objects into large JSON strings.
  • While encoding large objects that resulted in ~80MB JSON strings, Jason was using gigabytes of peak memory and resulting in OOM-kills. Jsonrs was created to fix this particular production issue, and was able to do the same encode using just the 80MB of the resulting string (plus 12 bytes of additional memory), and at around 5 times the speed.
  • Jsonrs’s performance advantage shrinks as the data being worked with gets smaller and less complex. You’re only going to see a big difference with fairly large or complex JSON.
  • OTP 24’s JIT noticeably improved the run time performance of Jason and Poison, so the performance gap has gotten a bit smaller since Jsonrs was first created. The memory usage gap doesn’t seem to have changed much from what I’ve seen, and is still very dramatic.

So the target demographic for Jsonrs is applications doing large JSON encodes, and these applications are likely to see a huge improvement in memory usage and a smaller but still significant improvement in speed.
I used to say that it isn’t worth using Jsonrs for people who aren’t dealing with encoding fairly large objects. If you aren’t going to see a huge difference in performance, why deal with the friction of building a Rust NIF in your project?
But now that precompiled libraries are available for common platforms, the barrier to using Jsonrs is much lower, and it might now be worth it for more people to use. I expect that you won’t see much of a difference if your application isn’t in the target demographic, but if you ever wanted to try it out anyway, now is a great time!

Showing Posts 1 to 6

cjbottaro

cjbottaro

We have this exact use case. We use Elixir to read Postgres CDC and write transactions as JSON to Nats Jetstream. We just kept increasing our Koob pods memory limit to work around the problem.

benhaney

benhaney OP

Oh yeah that definitely sounds like an ideal use case. If you try out Jsonrs for that I’d love to hear about it.

adammokan

adammokan

Great library @benhaney !

I rolled this into strategic portions of my data processing systems yesterday and I’m honestly a bit shocked at the difference I’m seeing on the memory usage.

kartheek

kartheek

Nice - can you share some metrics if it is possible?

adammokan

adammokan

Looking at the metrics overnight and digging into the amount of data processed - I see nearly a perfect 50% decrease in memory usage on our average inputs and in the largest 10% of the input payloads it is showing close to a 65% memory decrease.

Unfortunately the data we process could be considered “consistently inconsistent” and really depends on our customers’ behavior in various other platforms as we integrate with dozens of 3rd party systems and synchronize / process that data. Meaning that we have a range of input documents that can be as small as 50kb and as large as 25mb in size. My current customer workload averages just over five million of these transactions each day.

Another thing I should note is that my changes were purely around JSON decoding as that was the biggest area for improvement due to that wide range of document sizes and inconsistency there.

So take all of this as a grain of salt, given the variables at play.

benhaney

benhaney OP

Glad to have a real-world scenario that flexes decoding and still sees fairly substantial improvement. Until now, I’ve only seen large real-world use of Jsonrs in encode-heavy workloads, since that’s primarily what it’s been developed for. Thanks for sharing this!

— All posts loaded —

Where Next? Top

Trending in Announcing Top

wojtekmach
Hey everyone! Req is an HTTP client for Elixir that I’ve been working on for quite some time. There is already a lot of HTTP clients out...
New
handnot2
Samly can be used to enable SAML 2.0 Single Sign On in a Plug/Phoenix application. This library uses Erlang esaml to provide plug enabl...
New
woylie
Flop is an Elixir library that applies filtering, ordering and pagination parameters to your Ecto queries. offset-based pagination with...
New
MRdotB
I needed to reuse React components from my Chrome extension in my Phoenix/LiveView backend. I noticed that for Svelte/Vue, there are live...
New
garrison
Hobbes is a low-level distributed database for the Elixir programming language. Hobbes provides a simple, safe, and scalable storage lay...
New
marciok
Hi there! We created Gust: A task orchestrator inspired by Airflow. For those who have never heard about Aiflow, it’s a Python-based wor...
New
fuelen
Hi all! I want to present a small library which provides a mix task for generating an Entity-Relationship Diagram for Ecto schemas. You...
New

Other Trending Topics Top

mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
AstonJ
This showed up on my feed.. anyone heard of it? Just hype? Ox Alpha is a reasoning model designed for coding, sustained ag...
New
sergio
It’s not that it’s vocabulary is too advanced. It’s something worse. I get lost trying to follow even a paragraph written by Claude. It’...
New
sorenone
Today we’re releasing Oban for Python. Not an Oban client in Python. Not a pythonx wrapper embedded in Elixir. Nope, it’s a fully operati...
New
akoutmos
@hugobarauna, Dr. Dimitrios Koutmos (my brother) and I (Alex Koutmos) have been hard at work on writing a book on how you can use Elixir ...
New
pferriby
Introductory paragraph I’ll be looking for a keen junior or someone that has a couple of years experience in the real world (so you’ve be...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews