This is an apples-to-oranges comparison. The author admits this, and I'm not finding fault with the analysis. I do worry that those not familiar with various

This is an apples-to-oranges comparison. The author admits this, and I'm not finding fault with the analysis. I do worry that those not familiar with various ser/deser schemes for Java will draw the wrong conclusions. My take-away is that you should not blindly use Java serialization in cases where performance matters and you don't need the broad spectrum of use cases it covers. The main reason that Java serialization is so slow is that it is designed to persist self-describing, arbitrary object graphs. Self-describing = Full package+class names and versions. Any object graph containing Serializable classes available via the classloaders of both the sender and receiver. Arbitrary object graphs = The identity of objects is preserved. Let's say that 17 SalesOrder objects point to the same Customer object. salesOrderA.getCustomer() == salesOrderB.getCustomer() (identity in Java for those who haven't had the pleasure) is maintained. Oh, and JDK dynamic proxies are handled as a special case. And some other stuff, too. I had the pleasure a few months ago of copying the JDK's serialization code into my own package structure and adding logging so we could debug deser issues in an OSGi environment. From what I can tell, the impedence mismatch between OSGi classloading hierarchies and Java Serialization makes this combination a non-starter. The very-performant sample case provided in the blog posting works only for a list of flat objects. As soon as you try to preserve identity, you must implement a two-pass system where you deser placeholders and then resolve them later. I'm not suggesting that it isn't useful, but it probably constrains your serializable objects to such a degree that you'll be unhappy in other areas of your system. Kyro (as another commenter noted) seems like the best combination of small size/speed/general-ness that I've encountered thus far. There seem to be a reasonable number of pre-built Kyro serializers for common libraries such as Joda time. For a project I worked on recently where size was more important than speed, I took advantage of the similarity of the objects I was serializing and wrote a custom serializer which created dictionary look-ups on the fly. Repeated strings were turned into small integers, etc. I wish I didn't have to write it. In a nutshell, if you constrain the scope of the problem you are attempting to solve, the maximum possible performance of the system across covered use-cases goes up. Java Serialization's performance is relatively poor compared to less generalized schemes -- as expected.