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 .proto file gives you the benefits of something like JSON Schema: a place to document all your fields and what they mean, and a few very simple validation constraints like the expected types.
You already said it, but just wanted to back you up: The MessagePack benchmark is completely useless!
It consists of serializing 3 integers and a string 200,000 times.
MessagePack defines 27 different types¹ (excluding reserved ones) with variable bit length for the type identifier, length somewhat correlated with frequency of use.
A benchmark should therefor test real life data and a lot of it.
Their inability to produce such benchmark makes me question the sanity of splitting up e.g. the type marker for “array” into 3 different types depending on the size of the array — this adds complexity, so it would be good to know what exactly the authors based this design choice on, hopefully not that it made it faster to serialize a 3 element array 200,000 times.
This sort of "scientific dishonesty" is prevalent everywhere. I'd be surprised if the test creator didn't go out of their way to design the test specifically to push their agenda.
It's sad, really. The people who try to call bullshit on those sorts of claims are frequently drowned out by those who are blinded by the "4x faster!" etc.
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).
Comments
The "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 .proto file gives you the benefits of something like JSON Schema: a place to document all your fields and what they mean, and a few very simple validation constraints like the expected types.
You already said it, but just wanted to back you up: The MessagePack benchmark is completely useless!
It consists of serializing 3 integers and a string 200,000 times.
MessagePack defines 27 different types¹ (excluding reserved ones) with variable bit length for the type identifier, length somewhat correlated with frequency of use.
A benchmark should therefor test real life data and a lot of it.
Their inability to produce such benchmark makes me question the sanity of splitting up e.g. the type marker for “array” into 3 different types depending on the size of the array — this adds complexity, so it would be good to know what exactly the authors based this design choice on, hopefully not that it made it faster to serialize a 3 element array 200,000 times.
¹ http://wiki.msgpack.org/display/MSGPACK/Format+specification...
This sort of "scientific dishonesty" is prevalent everywhere. I'd be surprised if the test creator didn't go out of their way to design the test specifically to push their agenda.
It's sad, really. The people who try to call bullshit on those sorts of claims are frequently drowned out by those who are blinded by the "4x faster!" etc.
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).
Your debunking is appreciated, code speed!