5 ms·

I think the main advantages are: - network bandwidth/latency: smaller RPC consume less space, are received and responded to faster. - memory usa

I think the main advantages are: - network bandwidth/latency: smaller RPC consume less space, are received and responded to faster. - memory usage: less data is read and processed while encoding or decoding protobuf. - time: haven't actually benchmarked this one, but I assume CPU time spent decoding/encoding will be smaller since you don't need to go from ASCII to binary. Which means, all performance improvements. They come, as usual, at the cost of simplicity and ease of debugging.

al2o3cr 12y ago
"I assume X is more performant ... I haven't actually benchmarked it" I believe that's usually spelled "I am making this up".
- ithkuil 12y ago
  Or "I'm making an educated guess". Otherwise how can you get truly surprised when things turn out to be different in the real world :-) I'd also guess it would be more expensive during decoding. So let's compare that with some real data: https://github.com/eishay/jvm-serializers/wiki https://github.com/eishay/jvm-serializers/wiki (old wiki but with some graphs https://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking https://code.google.com/p/thrift-protobuf-compare/wiki/Bench...) it turns out that state of the art JSON serialisers aren't so bad after all, especially the serialisation.
- AYBABTME 12y ago
  I think "I assume X" is pretty clear and honest to the fact I'm making an assumption. I don't understand the need to aggressively emphase it. In a civilized discourse, if you disagree with my assumption because you know better, you should provide information as to why I'm wrong. And I'll be delighted to obtain this new knowledge. Otherwise, what's the point of your intervention?
- kentonv 12y ago
  The vast majority of performance judgments are made without benchmarking, because most of the time the answer is obvious enough without the need to measure. This is one of those times. Parsing the text "1234" is obviously going to be slower than loading its binary value, and text obviously takes more space than binary. That said, the internet is full of benchmarks backing this up if you care to Google it.

al2o3cr 12y ago

"I assume X is more performant ... I haven't actually benchmarked it" I believe that's usually spelled "I am making this up".

ithkuil 12y ago
Or "I'm making an educated guess". Otherwise how can you get truly surprised when things turn out to be different in the real world :-) I'd also guess it would be more expensive during decoding. So let's compare that with some real data: https://github.com/eishay/jvm-serializers/wiki https://github.com/eishay/jvm-serializers/wiki (old wiki but with some graphs https://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking https://code.google.com/p/thrift-protobuf-compare/wiki/Bench...) it turns out that state of the art JSON serialisers aren't so bad after all, especially the serialisation.
AYBABTME 12y ago
I think "I assume X" is pretty clear and honest to the fact I'm making an assumption. I don't understand the need to aggressively emphase it. In a civilized discourse, if you disagree with my assumption because you know better, you should provide information as to why I'm wrong. And I'll be delighted to obtain this new knowledge. Otherwise, what's the point of your intervention?
kentonv 12y ago
The vast majority of performance judgments are made without benchmarking, because most of the time the answer is obvious enough without the need to measure. This is one of those times. Parsing the text "1234" is obviously going to be slower than loading its binary value, and text obviously takes more space than binary. That said, the internet is full of benchmarks backing this up if you care to Google it.