The results of Serialization comparison is interesting. For complex Pojos the Protocol Buffers performs almost double as fast as Java Serialization. JSON seems to be very slow (I used Json-Lib). A good by product of the comparison was that a test harness emerged. This test harness can be easily extended to compare a new Serialization technology or different way to implement serialization of a previously compared technology. The results @ a glance: // =========[smaller the number the better] // Java Serialization...............:2135 // JSON Serialization...............:20523 // Google ProtoBuf Serialization....:1472 // =======================================

Missing details. Really :)

Oops. I think blog entry link should also appear here...

Aye a blog post/more information would be very useful even though the results are unsurprising. I'm quite surprised thought that only 3 methods of serialization are mentioned as well considering I can think of ones like * Hessian * Burlap * XML * Thrift Just off the top of my head.

XStream?

This is just unfair. Google' lib requires you to define the type structure manually upfront... With that "convenience" I'm really surprised how actually slow Google's implementation is. Apples to apples, please. Nikita Ivanov -- GridGain - Cloud Development Platform

Maybe because it is not measuring what it should really be measuring. William

This is just unfair. Google' lib requires you to define the type structure manually upfront... With that "convenience" I'm really surprised how actually slow Google's implementation is.

This was an informative post for me. Comparisons made by vendors are always labeled as being biased, hence we need those performed by community. BTW in most critical applications, the inconvenience of steps is neglectable in favor of speed and optimal behavior achieved. Google Protocol Buffer is a great model, esp. with its emphasis in immutability. Hopefully tools will emerge to ease the usage even more.

Would you still say it was relatively (comparatively) slow if the numbers excluded a number of factors including most importantly a baseline. Should you b compared X with Y or X - Z with Y - Z. What is Z? .....

Here is the missing link: http://whiteboardjunkie.wordpress.com/2009/09/14/serialization-options-compared/

This one seems more complete - http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking Ashwin.

Ashwin : There are some subtle differences between the two. The test is the results of an echo server implementation using Jboss Remoting. This is more realife comparison than what thrift-protobuf-compare is doing. Furthermore the domain object being serialized and deserialized is much more complex and complete that the specimen used in the other project. The object I am using for comparison has two types of collections, One Enum and a Java Bean instance as member variables. Another difference is that the comparison is also addressing the effect of transport on speed. thrift-protobuf-compare is a lot more complete in its shape and size than the artifact I had at the end of 2hrs of coding :-), No surprise there. However: Had there been only one way of doing anything thrift-protobuf-compare would not have existed anyways! What I have now is a pretty good framework for easily addiing and comparing other serialization options. I'd request participation from interested people, the code is open anyways. Nikita: Yes, the process complexity is there with Protocol Bufferes. I do not think it can be circumvented with some tooling. What I am thinking is Annotated Pojos that gives hints to a code generator ro create and compile .proto files.

Nikita: Yes, the process complexity is there with Protocol Bufferes. I think it can be circumvented with some tooling. What I am thinking is Annotated Pojos that gives hints to a code generator ro create and compile .proto files.

Those hessian numbers don't look right. Is that using Hessian 1 or Hessian 2? There's a big improvement for Hessian 2 both in performance and in serialization size.

Hmm. It's Hessian 2, but there's a good deal of extra overhead using it that way. Interesting. I should be able to improve that performance.

I should mention that is compares "benchmarks for protobuf, thrift, java, scala, few implementations of stax, binaryxml, json, xstream, javolution, hessian, air jordan avro, sbinary and JSON Marshaller."

http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking

http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking

I should mention that is compares "benchmarks for protobuf, thrift, java, scala, few implementations of stax, binaryxml, json, xstream, javolution, hessian, avro, sbinary and JSON Marshaller."

For those of you looking for a faster and easier to use protobuf implementation, you might want to check out this blog post. -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://fusesource.com/