Benchmarking JSON Generation in Ruby | Hacker News Reader

Benchmarking JSON Generation in Ruby

techblog.thescore.com

23 pointsbretthopper14 comments

Open articleView on HN

If you want json to be fast in Ruby, chances are you might want to look at https://github.com/ohler55/oj

Not sure how easy it is to jam oj into either of these two serializers though.

EDIT: rabl seems to support it according to the webpage

These benchmarks are already using OJ: https://github.com/thuva/json_serialization_benchmark/blob/m...

edit: although not sure it's being used properly yet

I forked and fixed the ActiveModel::Serializer and presenter examples to us Oj with MultiJson. I was unable to get rabl to work with the Oj engine for some reason. I didn't feel like spending any extra time to track it down. Anyway, from the benchmark, I was seeing that the Oj json serializer was approximately 3-10x faster than the normal to_json method.

https://github.com/mrinterweb/json_serialization_benchmark

Including Oj in Gemfile and not using it properly has caused some confusion. The original purpose of the benchmark was to test the relative performance of RABL, AMS, and presenters. In that case, the choice of the JSON library should not matter.

Having said that, it would still be nice to see the best performance we can get out of the 3 tools we're benchmarking. But, we need to get Oj working with all 3 of them in order to avoid unfair comparison of performance.

Make sure to never send Symbol objects to Oj, it will serialize them as ":foo". All other JSON libraries will represent them as "foo". And if you need to traverse your object graph to call #to_s on the symbols then the performance gain of Oj is lost.

I've had the exact same experience. Rabl is horribly slow in template generation...

Also, FWIW-- older versions of AMS, with caching, are a total crapshoot due to marshal dumping the objects into the cache and re-serializing them to JSON each time. Much better to cache the response itself instead of the objects making up the response.

Granted the caching feature was yanked out of AMS, but pretty painful for those of us that actually tried using it. Carrierwave + AMS caching = Problemzilla

At this point, we too have had Rabl, AMS, and Representers and the best one of the lot-- by far, for our use cases has been: Roar. https://github.com/apotonick/roar-rails

Plus, it's the only system which will de-serialize the data using the representer. Boom-shaka-laka.

AMS maintainer (though admittedly doing a poor job of it lately :/) here.

Which version were you benchmarking? The in-alpha 0.9 was a total re-write, so it'd be interesting to see how it compares.

Also, AMS has a caching feature (that is being re-written, too) that'd make for an interesting benchmark.

Versions are AMS 0.8.1 and RABL 0.9.3

Neat! I opened up some issues on the repo, I didn't see a link the first time I checked it out.

Thanks for the feedback and the issue report, Steve. I will take a look at the issues.

By the way, I would really appreciate it if you can answer this as you're in a better position to do so: http://techblog.thescore.com/benchmarking-json-generation-in...

Can I take this response as a sign AMS is not abandonware?

Some of us are getting concerned...

There was just a thread on the ML the other day about a new plan forward, actually.

No mention of jbuilder? When I looked at the popularity of json generators it seemed to be the most popular one, but now it occurred to me that it may be because it's included by default in Rails.

It would be great if someone familiar with JBuilder could make a PR to add support for it. It would actually be pretty simple to add.

Reply on news.ycombinator.com