It's for speed. I write web software in Ruby that runs on embedded devices. This software needs to communicate with a C backend that is consuming much of the available CPU power, so there's not much time left to waste on parsing the messaging protocol. I did some tests and found that JSON is significantly slower than simple key-value pair parsing (implemented as a state machine in C), which itself is half as fast as msgpack. This doesn't even consider the overhead of gzip compression.
Edit: here are my results, which lack the numbers for msgpack except a mention at the end (I hate linking to Posterous, but I haven't moved my blog yet): http://nitrogen.posterous.com/164964342
> I write web software in Ruby that runs on embedded devices.
Ok I gotta ask.... Why on earth would you do that? It seems like an exercise in masochism. I wasn't even aware that ruby would compile on embedded arches.
High-end embedded Linux (1.2GHz ARM CPUs). It saved development time, but I am considering rewriting everything in C. This is an example of what it's for (self-promoting link in 3, 2, 1...): http://www.nitrogenlogic.com/
Ahh, you mean literally embedded (perfectly legitimate use of the word). I associate it with DSPs and extremely low power chips where something like ruby is an absurdity. ARM is a great target for it, though.
I haven't. I'd expect them to be faster, but my biggest issue is CPU time rather than throughput. At any rate, my current solution is no longer a bottleneck on performance, but if it becomes one, I'll definitely be looking into other binary serialization formats.
Comments
It's for speed. I write web software in Ruby that runs on embedded devices. This software needs to communicate with a C backend that is consuming much of the available CPU power, so there's not much time left to waste on parsing the messaging protocol. I did some tests and found that JSON is significantly slower than simple key-value pair parsing (implemented as a state machine in C), which itself is half as fast as msgpack. This doesn't even consider the overhead of gzip compression.
Edit: here are my results, which lack the numbers for msgpack except a mention at the end (I hate linking to Posterous, but I haven't moved my blog yet): http://nitrogen.posterous.com/164964342
> I write web software in Ruby that runs on embedded devices.
Ok I gotta ask.... Why on earth would you do that? It seems like an exercise in masochism. I wasn't even aware that ruby would compile on embedded arches.
High-end embedded Linux (1.2GHz ARM CPUs). It saved development time, but I am considering rewriting everything in C. This is an example of what it's for (self-promoting link in 3, 2, 1...): http://www.nitrogenlogic.com/
Ahh, you mean literally embedded (perfectly legitimate use of the word). I associate it with DSPs and extremely low power chips where something like ruby is an absurdity. ARM is a great target for it, though.
Have you tried using thrift or protocol buffers, which aren't self-describing (introducing enormous overhead for <1MB messages.
I haven't. I'd expect them to be faster, but my biggest issue is CPU time rather than throughput. At any rate, my current solution is no longer a bottleneck on performance, but if it becomes one, I'll definitely be looking into other binary serialization formats.