As I said in the last post, Rust’s serialize library, specifically serialize::json is pretty slow. Back when I started this project a number of months ago, I wanted to benchmark to see how we compared to some other languages. There are a bunch of JSON benchmarks, but the one I chose was Cloudflare’s Go language. Goser, mainly because it was using a complex real world log structure, and they did the hard work of implementing benchmarks for encoding/json, goprotobuf, gogoprotobuf, and go-capnproto. I also included the Go ffjson and C++ rapidjson, which both claim to be the fastest JSON libraries for those languages. Here are the results I got:

language library format serialization (MB/s) deserialization (MB/s) C++ rapidjson JSON 294 164 (DOM) / 192 (SAX) Go encoding/json JSON 71.47 25.09 Go ffjson JSON 156.67 (not supported) Go goprotobuf Protocol Buffers 148.78 99.57 Go gogoprotobuf Protocol Buffers 519.48 319.40 Go go-capnproto Cap’n Proto 3419.54 665.35 Rust serialize::json JSON 40-ish 10-ish

Notes:

rapidjson supports both DOM-style and SAX-style deserializing. DOM-style means deserializing into a generic object, then from there into the final object, SAX-style means a callback approach where a callback handler is called for each JSON token.

supports both DOM-style and SAX-style deserializing. DOM-style means deserializing into a generic object, then from there into the final object, SAX-style means a callback approach where a callback handler is called for each JSON token. Go’s encoding/json uses reflection to serialize arbitrary values. ffjson uses code generation to get it’s serialization sped, but it doesn’t implement deserialization.

uses reflection to serialize arbitrary values. uses code generation to get it’s serialization sped, but it doesn’t implement deserialization. both goprotobuf and gogoprotobuf use code generation, but gogoprotobuf uses Protocol Buffer’s extension support to do cheaper serialization.

and use code generation, but gogoprotobuf uses Protocol Buffer’s extension support to do cheaper serialization. Cap’n Proto doesn’t really do serialization, but lays the serialized data out just like it is in memory so it has nearly zero serialization speed.

The Rust numbers are from a couple months ago and I couldn’t track down the exact numbers.

So. Yikes. Not only are we no where near rapidjson , we were being soundly beaten by Go’s reflection-based framework encoding/json . Even worse, our compile time was at least 10 times theirs. So, not pretty at all.

But that was a couple months ago. Between then and now, Patrick Walton, Luqman Aden, myself, and probably lots others found and fixed a number of bugs across serialize::json , std::io , generic function calls, and more. All this work got us to more than double our performance:

language library format serialization (MB/s) deserialization (MB/s) Rust serialize::json JSON 117 25

We’re (kind of) beating Go! At least the builtin reflection-based solution. Better, but not great. I think our challenge is those dang closures. While LLVM can optimize simple closures, it seems to have a lot of trouble with all these recursive closure calls. While having finished unboxed closures might finally let us break through this performance bottleneck, it’s not guaranteed.

All in all, this, and the representational problems from post 1 make it pretty obvious we got some fundamental issues here and we need to use an alternative solution. Next post I’ll start getting into the details of the design of serde.