[CoolGuySteve]

Definitely not, protobuf's strange wire format becomes apparent if you ever look at the hexdump of one or the profiler output of your favourite protobuffer-decoding C/C++ application.

They're actually kind of performance heavy for no benefit.

[imtringued]

I have once looked at a benchmark that compared protobuffer, message pack, json and a variety of other serialization formats. In terms of reducing bytes per message gzipped json was ahead of all of them at the cost of increased CPU time for gzip. Protobuffer did pretty poorly, the only benefit was decreased CPU usage. I'm sure you could use some other compression algorithm like LZMA to get both good compression and good performance for JSON messages.

[kentonv]

> In terms of reducing bytes per message gzipped json was ahead of all of them

Try gzipping the protobuf. Binary encoding and compression are different things which can be stacked. Gzipped protobuf should be smaller and faster than gzipped json in basically all cases.

[CoolGuySteve]

I use LZ4 (with "best" compression) for packet captures and replay with great results.

I get about a 37% compression ratio with extremely fast decoding, like 10 million packets per second off an SSD.

It was better than snappy, gzip, and bz2 for the trade-off of compression time, decompression time and file size.

As for protobuf: flatbuffers, capn proto, HDF5, and plain C structs all deliver much, much faster decoding time. It's really not the best answer for any serialization at this point but it's still inexplicably popular.

[touisteur]

Where you thinking of https://www.lucidchart.com/techblog/2019/12/06/json-compress... ?