MessagePack: Fast and Compact Serialization(msgpack.org)
msgpack.org
MessagePack: Fast and Compact Serialization
http://msgpack.org/
7 comments
For perl it's fast as long as you have a small payload. Here's my benchmarks using progressively bigger data structures.
We use this as data exchange format for our RPC services at Shopify. Incredibly fast, stable, easy to use.
Is this actually better than gzipped JSON?
This appears to be mmap-friendly. Since arrays have length values it's possible to jump around in a large messagepack-serialized structure without having to scan it. In JSON if you want to get to element 2 of an array you have to scan to the end of element 1. If there's a length value at the beginning of element 1 (as it looks like there is with msgpack) then you can seek straight past it.
Depends on how you define 'better', I guess - at the very least it has to be several magnitudes faster, with no overhead for compression, parsing, etc.
You can use type-conversion APIs with MessagePack if you use C++, Java or C#. It converts deserialized objects (=dynamically-typed) into statically-typed objects using templates (C++) or reflection + dynamic code generation (Java and C#). You don't have to write boring type-checking codes.
Note that this is a characteristic of the implementation, not of the data format. Some libraries for JSON like JSONIC (Java) provides these APIs.
Note that this is a characteristic of the implementation, not of the data format. Some libraries for JSON like JSONIC (Java) provides these APIs.
This sounds an awful lot like yet another ProtocolBuffers. What, if anything, new does it bring to the table?
This is schemaless. Protobufs require a .proto file that describes the data being serialized. A .proto file serves a similar purpose as the `struct` keyword in C.
MessagePack uses type prefixes to describe the data. For instance an unsigned 8-bit int starts with a `0xcc` followed by a byte.
MessagePack uses type prefixes to describe the data. For instance an unsigned 8-bit int starts with a `0xcc` followed by a byte.
Compatibility with JSON is a characteristic of MessagePack.
If you're already using JSON, you can use MessagePack as a faster/smaller substitution of JSON.
Since Protocol Buffers brings their original semantics, you must change lots of codes.
Since Protocol Buffers brings their original semantics, you must change lots of codes.
Schemaless (dynamic typing) is the most obvious difference.
I wrote about the pros/cons of schema here: http://news.ycombinator.com/item?id=2836242
I wrote about the pros/cons of schema here: http://news.ycombinator.com/item?id=2836242
Does it have it suitably low memory/CPU requirements to run on embedded devices?
How well does it work on ARM/MIPS?
How well does it work on ARM/MIPS?
It works very well at least on ARM.
I've used MessagePack on iPhone 3GS for the format of a dictionary file (> 100MB). I utilized mmap and zero-copy deserialization feature of MessagePack. And I received (and merged) some patches sent by those who use it on iPhone4/iPad2.
I've never tried to run it on MIPS. But it probably works if you use gcc.
(I'm author of MessagePack)
I've used MessagePack on iPhone 3GS for the format of a dictionary file (> 100MB). I utilized mmap and zero-copy deserialization feature of MessagePack. And I received (and merged) some patches sent by those who use it on iPhone4/iPad2.
I've never tried to run it on MIPS. But it probably works if you use gcc.
(I'm author of MessagePack)
In node.js, JSON is actually faster than msgpack: https://github.com/aikar/wormhole/issues/3
Also, due to V8's poor C++ API, msgpack doesn't support deserialization of 64 bit integers.
Also, due to V8's poor C++ API, msgpack doesn't support deserialization of 64 bit integers.
> Also, due to V8's poor C++ API, msgpack doesn't support deserialization of 64 bit integers.
JavaScript _does_not_ have a number type wide enough to hold 64-bit integer. V8 API has nothing to do with it.
JavaScript _does_not_ have a number type wide enough to hold 64-bit integer. V8 API has nothing to do with it.
Would be nice if suuport for RPC (and generally) for Erlang was better. It's "currently" in alpha.