encoding VS go_serialization_benchmarks

We took a similar approach in our JSON decoder. We needed to support sets (JSON object keys) that aren't necessarily known until runtime, and strings that are up to 16 bytes in length.

We got better performance with a linear scan and SIMD matching than with a hash table or a perfect hashing scheme.

See https://github.com/segmentio/asm/pull/57 (AMD64) and https://github.com/segmentio/asm/pull/65 (ARM64). Here's how it's used in the JSON decoder: https://github.com/segmentio/encoding/pull/101

Binary formats work well for some cases but JSON is often unavoidable since it is so widely used for APIs. However, you can make it faster in golang with this https://github.com/segmentio/encoding.

Would love to see results from incorporating https://github.com/segmentio/encoding/tree/master/json!

Try this one out https://github.com/segmentio/encoding it's always worked well for me

Converts any interface or string to JSON using the segmentio/encoding package. Also, the JSON method sets the content header to application/json.

If you're interested in super fast & easy JSON for that cache give this a try I've used it in prod & never had a problem.

Someone made a benchmark of serialization libraries in go [1], and I was surprised to see gobs is one of the slowest ones, specially for decoding. I suspect part of the reason is that the API doesn't not allow reusing decoders [2]. From my explorations it seems like both JSON [3], message-pack [4] and CBOR [5] are better alternatives.

By the way, in Go there are a like a million JSON encoders because a lot of things in the std library are not really coded for maximum performance but more for easy of usage, it seems. Perhaps this is the right balance for certain things (ex: the http library, see [6]).

There are also a bunch of libraries that allow you to modify a JSON file "in place", without having to fully deserialize into structs (ex: GJSON/SJSON [7] [8]). This sounds very convenient and more efficient that fully de/serializing if we just need to change the data a little.

--

1: https://github.com/alecthomas/go_serialization_benchmarks

2: https://github.com/golang/go/issues/29766#issuecomment-45492...

--

3: https://github.com/goccy/go-json

4: https://github.com/vmihailenco/msgpack

5: https://github.com/fxamacker/cbor

--

6: https://github.com/valyala/fasthttp#faq

--

7: https://github.com/tidwall/gjson

8: https://github.com/tidwall/sjson

The bebop definition specifies fixed-width types inside a struct. The format of structs cannot be changed, but there are efficiency gains by omitting all of the indices and header data. It's useless as the root message, but it's small and fast for a benchmark.

Hey everyone! Let me introduce you to mus-go - the fastest Golang serializer today. If you look at benchmarks (https://github.com/alecthomas/go_serialization_benchmarks), you can see that it could be almost twice as fast as its closest "competitor":

This might be of interest: https://github.com/alecthomas/go_serialization_benchmarks

The protobuf vs msgpack benchmarks are not too bad. Msgpack performs very decently.

https://github.com/alecthomas/go_serialization_benchmarks

Maybe submit a PR against https://github.com/alecthomas/go_serialization_benchmarks? That covers a ton of serialization formats already, so adding your library would be cool and avoid wheel reinvention.