MessagePack saves a little bit of space and CPU ... but not a lot:
https://media.licdn.com/dms/image/v2/D5612AQF-nFt1cYZhKg/art...
Source: https://www.linkedin.com/pulse/json-vs-messagepack-battle-da...
https://media.licdn.com/dms/image/v2/D5612AQF-nFt1cYZhKg/art...
Source: https://www.linkedin.com/pulse/json-vs-messagepack-battle-da...
Looking at the data, I'm inclined to agree that not much CPU is saved, but the point of MessagePack is to save bandwidth, and it seems to be doing a good job at that.
Significante with regards to what? Not doing anything? Flipping the toggle to compress the response?
To me it doesn't. There's compression for much bigger gains. Or just, you know, just send less data?
I've worked at a place where our backend regularly sent humongous jsons to all the connected clients. We were all pretty sure this could be reduced by 95%. But, who would try to do that? There wasn't a business case. If someone tried succeeded, no one would notice. If someone tried and broke something, it'd look bad. So, status quo...
I've tried messagepack a few times, but to be honest the hassle of the debugging was never really worth it
Thus, the only thing you can do after that to improve performance is to reduce bytes on the wire.
In a discussion about using messagepack that doesn't really sound like messagepack is winning.
99.9999999% of the data sent across the network in that Datacenter will never be read by humans directly. Why put it into a textual form?
Reports there are that JSON is still the speed champ, by a healthy measure. I am among many who seem to chalk this up to JSON encoding/decoding being fantastically well optimized, having many heavily-invested in very well tuned & optimized libraries available.
(Ed: well, https://github.com/djkoloski/rust_serialization_benchmark only shows rust options, but somewhat contradicting this. JSON encoding appears ~3x slower, when looking at best CBOR & JSON performances)
This article feels quite broad & high level, as a general introduction. With a couple graphs thrown in at the end to try to close the deal. The space savings I tend to think are probably reasonably representative regardless of the library being tested. But the speed is going to vary greatly, and this is one of very few examples I've seen where CBOR comes out faster. The article does not provide any information that I can see about what the test is, what data or libraries are being tested.
It is worth noting that CBOR has heightened interest very recently, as the recent Kubernetes 1.32 shipped an alpha feature to talk in CBOR. The very good library below has gotten some good attention. https://github.com/fxamacker/cbor
Encoding/Decoding an array of strings in Javascript is going to have a completely different performance profile than Encoding/Decoding an array of floats in a lower level language like C.
If you have a lot of strings, or lots of objects where the total data in keys is similar to the total data in values, then msgpack doesn't help much.
But when you have arrays of floats (which some systems at my work have a lot of), and if you want to add a simple extension to make msgpack understand e.g. JavaScript's TypedArray family, you can get some very large speedups without much work.