I'd love to see some benchmarks comparing the size of gzipped messagepack vs gzipped json for a wide bunch of example messages. If this is better than json, and has objective-c libraries, it could be magic for our purposes! (file size is very important when making mobile apps).
You're Using JSON, Why not MessagePack?
51–60 of 66 posts
Re: You're Using JSON, Why not MessagePack?
#52What about bencoding? http://wiki.theory.org/BitTorrentSpecification#bencoding Seriously, this is not an either or question. Just use the right tool for the right job. I wouldn't serialize my data to XML on a micro controller but so I wouldn't drive my JS frontend with binary serialized data.
This was one of my thoughts, too. Bencoding is hardly ever used outside of Bittorrent, but it's a useful serialisation tool.
Re: You're Using JSON, Why not MessagePack?
#53Zip both resulting strings and I bet you it's a wash. Since JSON is mostly used (at least by me) for sending data to client side javascript, it doesn't make a difference. JSON is just easier.
Yup. We tested messagepack a while back in our environment. Speed difference was 2% versus gzipped JSON. Not enough to invest time in changing a working system and losing human readability.
Re: You're Using JSON, Why not MessagePack?
#54with orthogonal GZIPing, I'm happy using JSON (which allows me to read the data in my browser debugger, curl, etc.), while getting good compression.
Re: You're Using JSON, Why not MessagePack?
#55The "4x faster than Protocol Buffers" claim is misleading, as I have explained before: http://news.ycombinator.com/item?id=2146147 I'm working on a Protocol Buffer library that can serialize/deserialize to either JSON or Protocol Buffers. That way you can do all your development with JSON, but if you ever find you need the efficiency improvements of a binary format, you can just change your Serialize() call. Having a…
Your debunking is appreciated, code speed!
Re: You're Using JSON, Why not MessagePack?
#56Earlier quoted context omitted.
Citation needed, especially since the node-msgpack library docs say it's anywhere from 1.2-3X faster. https://github.com/pgriess/node-msgpack
Good point... a Node MQ project formerly based on msgpack recently switched to JSON and increased its performance by almost 200%: https://github.com/aikar/wormhole/issues/3 I've done several of my own benchmarks as well and can confirm that the current Node JSON implementation is much faster than MessagePack. Their benchmarks are most likely quite old.
That mostly speaks to the quality of node's MessagePack implementation, nothing more. Benchmarking data format serialization is hard, because one poor implementation throws things off.
Re: You're Using JSON, Why not MessagePack?
#57Earlier quoted context omitted.
> Is there a Ruby module with no C extension? Why is the "with no C extension" part important to you?
By the way, there is a pure ruby version, not sure why you'd use it over the cext though: https://github.com/hiroshinakao/msgpack-pure
JRuby. Windows, if you don't have the compile stuff installed.
This could be alleviated with Ruby FFI on top of a really good C implementation, but FFI is tricky.
Re: You're Using JSON, Why not MessagePack?
#58The "4x faster than Protocol Buffers" claim is misleading, as I have explained before: http://news.ycombinator.com/item?id=2146147 I'm working on a Protocol Buffer library that can serialize/deserialize to either JSON or Protocol Buffers. That way you can do all your development with JSON, but if you ever find you need the efficiency improvements of a binary format, you can just change your Serialize() call. Having a…
What sort of state is said library in and what licensing do you plan for this? I have a need for something like this (and we have implemented a working hack to get past our current problem).
Re: You're Using JSON, Why not MessagePack?
#59For the same reasons we are in the process of switching from Protocol Buffers back to JSON: * It does not support our languages. Is there a Ruby module with no C extension? A C# library? Lua? What about that really cool language coming out next week? What about C? * Even if it does, why have to deal with someone else's poor API design? JSON has a million parsers for everything, and if by chance you don't like any of…
It does not support our languages. Is there a Ruby module with no C extension? A C# library? Lua? What about that really cool language coming out next week? What about C?
Exactly. I love having JSON libraries at my disposal no matter whether I'm coding in Python, C, Haskell, Racket, JS, whatever. That's hard to beat for coders like me (generalists).
Re: You're Using JSON, Why not MessagePack?
#60Earlier quoted context omitted.
Good point... a Node MQ project formerly based on msgpack recently switched to JSON and increased its performance by almost 200%: https://github.com/aikar/wormhole/issues/3 I've done several of my own benchmarks as well and can confirm that the current Node JSON implementation is much faster than MessagePack. Their benchmarks are most likely quite old.
That mostly speaks to the quality of node's MessagePack implementation, nothing more. Benchmarking data format serialization is hard, because one poor implementation throws things off.
MessagePack in Node isn't much more than bindings to the C++ library (https://github.com/pgriess/node-msgpack/blob/master/src/msgp...). For me the bottom line was "What's faster in Node, for my project, right now?", and the answer was JSON.
There are benefits to MessagePack that have already been mentioned here, namely not having to base64 binary data first (smaller size), but that's true for any binary message format. I'd love to see some other binary formats thrown into the ring and see how they compare to MessagePack in both size efficiency and encode/decode performance. BSON seems like an interesting option, but I don't know enough about it to comment...