Get the latest tech news
Optimizing Ruby's JSON, Part 4
In the previous post, we established that as long as ruby/json wasn’t competitive on micro-benchmarks, public perception wouldn’t change. Since what made ruby/json appear so bad on micro-benchmarks was its setup cost, we had to find ways to reduce it further.
As mentioned in previous parts, I expected the extra allocation would be the main issue, and that re-using the JSON::State object would put us on par with Oj, but it’s always good to revalidate our assumptions: This can probably be optimized further by writing directly in the output buffer so that we don’t need to copy, and maybe even use log to compute upfront how many digits the number has, but that was good enough for now, so I went back to reduce setup cost. Just like malloc / free etc, the performance of malloc_usable_size varies a lot depending on the allocator, I haven’t benchmarked on Linux, nor with jemalloc, so it’s possible that this overhead would have been negligible there, and that may be why Ruby doesn’t try to skip that call when possible?
Or read this on Hacker News