Hacker News Reader

Comment by k__ | Hacker News Reader

I read somewhere the problem with MsgPack is, that JSON has a rather fast parser build into JavaScript that beats the MsgPack parser. So you would have to check if the saved bandwidth would be enough to justify the slower parsing.

Would be interesting if this still holds true with a WASM implementation.

View on HN

Since WASM can't create or access JavaScript objects directly, I bet it's still slower. MessagePack (or my preference, CBOR) is still useful and faster than JSON if you need to exchange raw bytes from typed arrays (for JSON you'd need to encode them, e.g. in base64).

That's the case with Perl at least. Both JOSN::XS and Cpanel::JSON::XS are faster than Data::MessagePack and Sereal on an iMac 2009 with Yosemite. On Linux Sereal is 53% faster than Data::MessagePack, but the rest of the benchmark is quite similar. CBOR::XS beats just about any data serializer. Sereal is quite sophisticated, it can compress data using snappy, zlib and zstd.

            Rate msgpack  sereal cjsonxs  jsonxs  cborxs
    msgpack 204848/s      --     -2%     -6%    -18%    -34%
    sereal  208207/s      2%      --     -4%    -16%    -33%
    cjsonxs 217825/s      6%      5%      --    -13%    -29%
    jsonxs  249011/s     22%     20%     14%      --    -19%
    cborxs  308571/s     51%     48%     42%     24%      --

All the module versions tested are current. Here is the code for this benchmark:

https://hastebin.com/wazuqovexo.pl

I used to think binary formats for network protocols were a really good idea until I found out how big the TCP header itself can be. Saving a few bytes from your payload by using binary representations of integers doesn't make a huge difference when the TCP header is 60 bytes.

Just to add another dimension to your analysis, if you're sending large binaries the 33% overhead of Base64 adds up pretty quickly. It may not apply to your use case but if you are delivering images or video over a websocket it can make a big difference.

On the other hand, gzip can reclaim most of those 33% with Huffman encoding.

Only in some cases. Also it increases latency.

Here’s my old article about Microsoft’s binary XML format: http://const.me/articles/net-tcp/ As you see, for some payloads it compresses XML to 9% of the original size.

The data contract serializer included in .NET framework (and even in .NET Core) can read & write objects directly from/to this binary serialization format, without intermediate text XML anywhere.

That's something I hadn't considered. I'll have to do some benchmarking. Thanks!

Reply on news.ycombinator.com