High performance serialization: Java vs Google Protocol Buffers vs …?

Question

For some caching I\'m thinking of doing for an upcoming project, I\'ve been thinking about Java serialization. Namely, should it be used?

Now I\'ve previously writt

Answer 1

You might also have a look at FST, a drop-in replacement for built-in JDK serialization that should be faster and have smaller output.

raw estimations on the frequent benchmarking i have done in recent years:

100% = binary/struct based approaches (e.g. SBE, fst-structs)

• inconvenient
• postprocessing (build up "real" obejcts at receiver side) may eat up performance advantages and is never included in benchmarks

~10%-35% protobuf & derivates

~10%-30% fast serializers such as FST and KRYO

• convenient, deserialized objects can be used most often directly without additional manual translation code.
• can be pimped for performance (annotations, class registering)
• preserve links in object graph (no object serialized twice)
• can handle cyclic structures
• generic solution, FST is fully compatible to JDK serialization

~2%-15% JDK serialization

~1%-15% fast JSon (e.g. Jackson)

• cannot handle any object graph but only a small subset of java data structures
• no ref restoring

0.001-1% full graph JSon/XML (e.g. JSON.io)

These numbers are meant to give a very rough order-of-magnitude impression. Note that performance depends A LOT on the data structures being serialized/benchmarked. So single simple class benchmarks are mostly useless (but popular: e.g. ignoring unicode, no collections, ..).

see also

http://java-is-the-new-c.blogspot.de/2014/12/a-persistent-keyvalue-server-in-40.html

http://java-is-the-new-c.blogspot.de/2013/10/still-using-externalizable-to-get.html