Gojay

You are right. I totally missed it in the first few tables. The lack of allocs for JsonParser was definitely a big win for my project. When processing at high rps (40k msg/sec),…

You don't have to use structs tags (nor even structs) to use encoding/json. In fact I often don't as a lot of my usage is with maps rather than structs. I did some testing with…

(ffjson author here) The main feature that ffjson has that most of the non-stdlib JSON libraries is stdlib compatibility. Eg, the same struct-tags and interfaces used in stdlib…

It's actually the next milestone, a generator for structs, maps and slices. Until now the goal was to make it ready for some high traffic services in production. These traffic…

Nope, it's quite easy to integrate unicode parsing :) just need to check for "\u1234" strings in JSON as it is valid, also need to check for utf16 surrogates. Standard package…

encoding/json's Marshal and Unmarshall uses reflect and struct tags. This library doesn't: you have to define a function to make your struct satisfy an interface.

That's fine, but this library isn't a drop-in replacement for encoding/json; to be that, it has to work for people who expect tagged structs to round-trip through it, which won't…

Performance is a real issue for Go's standard JSON, but this is a lot of extra boilerplate code to have to write (I'd probably codegen most of this if I had to), so I'd assume…

You don't have to use structs tags (nor even structs) to use encoding/json. In fact I often don't as a lot of my usage is with maps rather than structs. I did some testing with…

To see how this fares against native code, I ported their benchmark to Rust's JSON library https://serde.rs/. Disclaimer: I am a maintainer of Serde. Numbers and graphs:…

The next milestone is actually to write a code generator for structs, maps and slices.

It's actually the next milestone, a generator for structs, maps and slices. Until now the goal was to make it ready for some high traffic services in production. These traffic…

There's an important distinction between the decoding speed of documents and overall throughput. Wonder what can be done to realistically generate something approximating a real…

I have been using ffjson[1] in a couple of private projects, which generates code to encode/decode data, which supposedly is faster than the json library from Go's standard…

How does this compare to http://ugorji.net/blog/go-codecgen ?

The fastest Go JSON parser I know of is https://github.com/buger/jsonparser. I've used that one in production quite successfully. I don't see that in the comparative benchmarks…

I have been using ffjson[1] in a couple of private projects, which generates code to encode/decode data, which supposedly is faster than the json library from Go's standard…

(ffjson author here) The main feature that ffjson has that most of the non-stdlib JSON libraries is stdlib compatibility. Eg, the same struct-tags and interfaces used in stdlib…

Is it? Kubernete switched from the native go Json parser to codec for performance increase. http://ugorji.net/blog/go-codecgen

That's exactly what go-codec does

Would be handy if it included a utility to generate the (un)marshaling functions, so that can just be done as a build step. So far we’ve used https://github.com/mailru/easyjson…

To see how this fares against native code, I ported their benchmark to Rust's JSON library https://serde.rs/. Disclaimer: I am a maintainer of Serde. Numbers and graphs:…