Miles to go ...

Benchmarking Msgpack with CBOR

JSON is by far the most popular serialization format used by programmers due to its immense popularity in web. It is self describing, because it is encoded in human readable text, and support a set of data types that are available in most of the languages. Nevertheless, there are few shortcomings as well.

I am going to pick two alternative for JSON, Msgpack and CBOR. I am also of the opinion that both these format can do better in terms of CPU and Memory footprint compared to JSON serialization. Hence, will be focusing on how they are going to compare with each other.

Support of data types

Both formats have support for the common set of types nil, number, boolean, string, binary, array and map. And both formats have support for extending its encoding format for application defined types. Msgpack calls it as extension types and CBOR calls it as tags. Between them I feel CBOR’s provisions are more future proof than Msgpack.

CPU benchmark

For CPU benchmark we will confine the measurements to the common set of data types defined by JSON standard.

Following bar chart show the time taken to encode basic data types - nil, int64, uint64, bool, bytes, string, array and map. This benchmark was done in go-language, using msgpack package and gson package. Source code is available here, here and here.

Encode benchmark between msgpack and cbor

Following bar chart show the time taken to decode basic data types - nil, int64, uint64, bool, bytes, string, array and map. This benchmark was done in go-language, using msgpack package and gson package.

Decode benchmark between msgpack and cbor

Memory footprint

Following bar chart shows on-the-wire footprint when encoding basic data types:

Memory footprint msgpack and cbor

As far as memory footprint or on-the-wire footprint goes, both the format give comparable efficiency.