Java serialization versus AMF/Hessian serialization

Update: I added also compression. The result is the same, Hessian is the clear winner. Not quite sure why deflate takes so much time when applied to AMF output, but I was able to reproduce this result with different inputs.

Two months ago I was asked by several guys from JUG Gothenburg to do a comparison between AMF and classic Java serialization. I was not able to answer at the moment, because I had never thought about it nor had I performed any tests. Now I extended my mini-benchmark from my previous post and I also serialized the objects using Java serialization. The results are below, and you can see from the results that the size of compressed data is much larger for Java serialization (I used Java 1.6). Without looking at the code from ObjectOutputStream I assume that there are no techniques like detecting duplicate values and writing references or writing small number on fewer bytes.

My suggestion is to use AMF/Hessian rather than Java serialization whenever you can – you will be able to save a lot of bandwidth.

The result table is below, and you can download the source code from here.

Avg Time (microseconds) Data size (kbytes)
AMF3 9945 28
Hessian 4675 29
Java serialization 6400 60
AMF3+Deflate 34479 14.5
Hessian+Deflate 6076 14
Java serialization+Deflate 19193 22
XML 22064 158
XML+Deflate 27336 18

9 thoughts on “Java serialization versus AMF/Hessian serialization

  1. Java Serialization has detection of duplicate and writing of references (named TC_REFERENCE in ObjectOutputStream) like AMF3 I suppose.

    As all streams, java serialization can be compressed by encapsulating the stream with GZipOutputStream or DeflaterOutputStream : to be complete, it would be interesting to know how does AMF3+deflate or gzip compares to java serialization+deflat or gzip ?

  2. Java serialization+deflate is still not optimal especially when compared with hessian+deflate – I will add the results and source code this week.

  3. weird. i see quite different numbers comparing hessian and java ser:

    JBossSerializer: 1344ms (Size: 849289 bytes)
    HessianSerializer: 1140ms (Size: 1239018 bytes)
    PlainSerializer: 985ms (Size: 699312 bytes)
    PlainGZipSerializer: 1328ms (Size: 306680 bytes)

    not only plain is faster, but it also is significantly more compact.

  4. Depends a lot on the input data. Take a look on Hessian specifications. Hessian/AMF are working very well when the object graph contains a lot of identical objects. For example imagine a list of Employees owning an object Town. Probably you will have 10 different Town objects at 1000 Employees. This case is very common for the UI’s – imagine that you have a grid when you want to display the Employees – you can have customer requests to display also the Town or another associated/composite objects.

    Can you send me your input data (if it’s not confidential)? I can take a quick look.

  5. I wonder a reason AMF3 + deflate is inherently slow compared to Java serialization + deflate might be that the deflate algorithm has more “work” to do in attempting to deflate the already-lean AMF3. For example, deflate may create a large look-back dictionary, and also find it less useful, when processing the less-repetitive AMF3 format.

    Which has an efficient representation for passing multiple objects of the same class and multiple instances of the same string object.

  6. I think to avoid misunderstandings it should be noted that this is a less complete test than James Ward’s benchmarks. I’d be interested in seeing a more end-to-end comparison in which I would bet that AMF gains on Hessian (possibly quite a bit, but just a guess).

    It does say “serialization” in the description but I can imagine some taking this as a more complete test than it is.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>