4 ms·

MessagePack saves a little bit of space and CPU ... but not a lot: https://media.licdn.com/dms/image/v2/D5612AQF-nFt1cYZhKg/article-inline_image-shrink_1000_14

by toomim 2y ago

MessagePack saves a little bit of space and CPU ... but not a lot: https://media.licdn.com/dms/image/v2/D5612AQF-nFt1cYZhKg/article-inline_image-shrink_1000_1488/article-inline_image-shrink_1000_1488/0/1703965440210?e=2147483647&v=beta&t=XOmhYJP5X6iYJ17RYsk3SjX9FTvfcZbQFP-OTOg6flk https://media.licdn.com/dms/image/v2/D5612AQF-nFt1cYZhKg/art... Source: https://www.linkedin.com/pulse/json-vs-messagepack-battle-data-efficiency-akshay-singh-kanawat-7dx2c https://www.linkedin.com/pulse/json-vs-messagepack-battle-da...

koito17 2y ago
An approximate 20% reduction in bandwidth looks significant to me. I think the problem here is that the chart uses a linear scale instead of a logarithmic scale. 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.
- motorest 2y ago
  > An approximate 20% reduction in bandwidth looks significant to me. Significante with regards to what? Not doing anything? Flipping the toggle to compress the response?
- tasuki 2y ago
  > An approximate 20% reduction in bandwidth looks significant to me. 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...
  - bythreads 2y ago
    In a system that requires the absolute speediest throughput compression is actually usually the worst thing in a parsechain - so parsing without first decompression is valuable. I've tried messagepack a few times, but to be honest the hassle of the debugging was never really worth it
  - junon 2y ago
    Compression is a performance killer for intra-DC communication. You typically avoid it at all costs when doing RPC within the same AZ/DC. Thus, the only thing you can do after that to improve performance is to reduce bytes on the wire.
    - imtringued 2y ago
      Okay so you just use plain JSON again... In a discussion about using messagepack that doesn't really sound like messagepack is winning.
      - junon 2y ago
        A 20% reduction of bytes on the wire is not losing. 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?
dns_snek 2y ago
That's a bad benchmark, it doesn't show what type of data is being encoded or the programming language. 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.
- crabmusket 2y ago
  I came here to say this. I did my own benchmarks on JSON versus msgpack. I shall have to reproduce and publish them one day. 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.
jauntywundrkind 2y ago
CBOR is derived from MessagePack, and is used throughout BlueSky/AtProto. 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 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 https://github.com/fxamacker/cbor

by toomim 2y ago

koito17 2y ago

An approximate 20% reduction in bandwidth looks significant to me. I think the problem here is that the chart uses a linear scale instead of a logarithmic scale. 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.

motorest 2y ago
> An approximate 20% reduction in bandwidth looks significant to me. Significante with regards to what? Not doing anything? Flipping the toggle to compress the response?
tasuki 2y ago
> An approximate 20% reduction in bandwidth looks significant to me. 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...
- bythreads 2y ago
  In a system that requires the absolute speediest throughput compression is actually usually the worst thing in a parsechain - so parsing without first decompression is valuable. I've tried messagepack a few times, but to be honest the hassle of the debugging was never really worth it
- junon 2y ago
  Compression is a performance killer for intra-DC communication. You typically avoid it at all costs when doing RPC within the same AZ/DC. Thus, the only thing you can do after that to improve performance is to reduce bytes on the wire.
  - imtringued 2y ago
    Okay so you just use plain JSON again... In a discussion about using messagepack that doesn't really sound like messagepack is winning.
    - junon 2y ago
      A 20% reduction of bytes on the wire is not losing. 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?

dns_snek 2y ago

That's a bad benchmark, it doesn't show what type of data is being encoded or the programming language. 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.

crabmusket 2y ago
I came here to say this. I did my own benchmarks on JSON versus msgpack. I shall have to reproduce and publish them one day. 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.

jauntywundrkind 2y ago

CBOR is derived from MessagePack, and is used throughout BlueSky/AtProto. 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 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 https://github.com/fxamacker/cbor