(outdated) Kryo v1 benchmarks
Note this page is for a very old version of Kryo. See the home page for the latest documentation and up to date benchmarks.
Please use the Kryo discussion group for support.
The results below were obtained using the thrift-protobuf-compare project. There you will find the source for the benchmarks used to generate the charts displayed here. The project also has a benchmarking page that compares 20+ Java serialization libraries, including Kryo.
Besides the benchmark project linked above, a project called memcached-session-manager has done some additional benchmarking.
Google's protobuf project beats out most other Java serialization libraries, so is a good baseline to compare against:
The bars labeled "kryo" represent out of the box serialization. The classes are registered with no optimizations.
The bars labeled "kryo optimized" represent the classes registered with optimizations such as letting Kryo know which fields will never be null and what type of elements will be in a list.
The bars labeled "kryo compressed" represent the same as "kryo optimized" but with deflate compression. The compression has a small performance hit to decode and a large performance hit to encode, but may make sense when space or bandwidth is a concern. The round trip time with compression is shown below.
Although Kryo is doing everything at runtime with no schema and protobuf uses precompiled classes generated from a schema, Kryo puts up a fight. The two projects are basically tied in serialization size and protobuf just squeaks ahead in serialization speed.
There are other differences between the projects that should be considered.
Protobuf requires a .proto file to be written that describes the data structures. With Kryo, the classes to be serialized only need to be registered at runtime.
The .proto file is compiled into Java, C++, or Python code. Third party add-ons exist to use protobuf with many other languages. Kryo is designed only to be compatible with Java and provides no interoperability with other languages.
The protobuf compiler produces builders and immutable message classes. From the protobuf documentation: _Protocol buffer classes are basically dumb data holders (like structs in C++); they don't make good first class citizens in an object model. If you want to add richer behavior to a generated class, the best way to do this is to wrap the generated protocol buffer class in an application-specific class.
With Kryo, instances of any class can be serialized, even classes from third parties where you do not control the source.
Protobuf supports limited changing of the .proto data structure definition without breaking compatibility with previously serialized objects or previously generated message classes. With Kryo, the class definition during deserialization must be identical to when the class was serialized. In the future Kryo may support optional forward and/or backward compatibility.
Java's built-in serialization is slow, inefficient, and has many well-known problems (see Effective Java, by Josh Bloch pp. 213).
