Deserializing JSON Fast (2020)

If you want to optimize for minimal deserialization time, consider using FlatBuffers for serialization: <a href="https:&#x2F;&#x2F;google.github.io&#x2F;flatbuffers&#x2F;" rel="nofollow">https:&#x2F;&#x2F;google.github.io&#x2F;flatbuffers&#x2F;</a>

So this isn&#x27;t <i>really</i> deserializing JSON as some of the optimizations they are making are based on them actually targeting a JSON subset. That removes a bunch of conditions and branches. Still, it&#x27;s interesting, and a great example of ways handling trusted data is faster than untrusted (and I guess more importantly how people writing handlers for untrusted code can accidentally &quot;optimize&quot; things into security flaws :D)<p>That said, in my experience the real cost of JSON parsing turns out to be constructing the in memory representation of the sources. I&#x27;m sure JSON parsing for the purpose of deserializing specific types would be faster as you might be able to avoid some allocations (e.g. imagine a vector type `struct Vector { float elements[4]; }` a generic JSON representation would result in two allocations)

&gt; The upside of those tradeoffs are that <i>it improves our query throughput by about 20% compared to simd_json</i><p>Woah, that&#x27;s impressive.<p>I wonder if `str` is maybe an antipattern for a lot of JSON use cases where you can perform utf8 validation lazily or avoid it altogether for data you don&#x27;t need.<p>Given a service architecture with mTLS, and so long as you aren&#x27;t doing anything sensitive based on the data, I could see an approach like this being valuable.<p>That said, I also wonder if it&#x27;s worth pushing JSON into use cases like this to begin with?

Not that the optimisation isn&#x27;t interesting but if the query is column-based, wouldn&#x27;t it make more sense to use a binary column-oriented format like Apache Parquet [0]? Or perhaps a binary format like Protobuf, Webpack, Cap&#x27;n&#x27;proto etc.?<p>Are there other concerns that cause JSON to make sense?<p>[0]: <a href="https:&#x2F;&#x2F;parquet.apache.org&#x2F;documentation&#x2F;latest&#x2F;" rel="nofollow">https:&#x2F;&#x2F;parquet.apache.org&#x2F;documentation&#x2F;latest&#x2F;</a>

Not Rust, but for C++ I have found a lot of memory and CPU perf can be realized by knowing what is being parsed into and using that. Most JSON parsing optimize on array&#x2F;object&#x2F;number&#x2F;bool&#x2F;null and not things like unsigned integer being much faster to parse than a float(floating point hit cpu bottlenecks around 1GB&#x2F;s). Additionally, allowing for compile time options to further optimize is much easier. Essentially most JSON parsers are type erased. <a href="https:&#x2F;&#x2F;github.com&#x2F;beached&#x2F;daw_json_link" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;beached&#x2F;daw_json_link</a><p>So this correlates with some of the findings the post has. One optimization that should show great promise is that if one knows that they have an array of some types like numbers&#x2F;unsigned int&#x2F;strings, that can greatly simplify and allow for SIMD&#x27;ification of it.

Going further down the road of only doing what your requirements demand (not writing a general purpose parser), I really enjoyed this talk. <a href="https:&#x2F;&#x2F;media.handmade-seattle.com&#x2F;context-is-everything&#x2F;" rel="nofollow">https:&#x2F;&#x2F;media.handmade-seattle.com&#x2F;context-is-everything&#x2F;</a>

&quot;we don&#x27;t need error handling because we output the thing&quot;<p>i&#x27;m wondering why the hell its not a faster format? json is awful for storing ... anything, but a good compromise given that &quot;everyone knows what it is&quot;