Native C/C++ Like Performance For Java Object Serialisation

http://mechanical-sympathy.blogspot.com/2012/07/native-cc-like-performance-for-java.html

by pron • 14 years ago

36 11 14 years ago

mechanical-sympathy.blogspot.com

Is the unsafe version doing bounds-checking? I imagine de-serializing is much faster without branching, although probably not a great idea.

Hadoop's IPC protocol does something similar to what this article describes. They roll their own serialization format[0] and write to a wrapped ByteArrayOutputStream[1].

[0]: Example of a serialized object: https://github.com/apache/hadoop-common/blob/fdf697eebc95cbb...

[1] https://github.com/apache/hadoop-common/blob/fdf697eebc95cbb...

pron2• 14 years ago

No. No bounds checking.

dxbydt• 14 years ago

You use unsafe.putLong(), unsafe.putByte(), unsafe.putInt() to directly store a value into a given memory address. You then use unsafe.getLong() etc to directly read those values back from memory. This get you native C-like performance of only 78 ns, roughly 130 times faster than Java's 11,000 ns, very impressive! But when it comes to allocating memory, you use "new byte[1024]", a straight Java call. Using malloc ie. unsafe.allocateMemory(...), to get a larger byteblock and writing into it would probably speed up the routine even more. You also have the free ie. unsafe.freeMemory for the cleanup. (http://www.docjar.com/docs/api/sun/misc/Unsafe.html )

mjpt7773• 14 years ago

The byte[] buffer is deliberate because that is what will typically be passed to the network or IO device, so easier integration.

If you check the code you will see the buffer is only allocated once so the cost is not an issue.

pron2• 14 years ago

Network i/o puts a much bigger constraint on latency and throughput than serialization, so in practically all cases serializing to ByteBuffers using the standard ByteBuffer API (without resorting to Unsafe) would be just fine.

mjpt7773• 14 years ago

State of the art network hop is less than 3us so this is relevant. For on box IPC which can be as low as 100ns then very very relevant.

shrughes• 14 years ago

CPU can easily be the throughput bottleneck if you add enough network bandwidth.

It doesn't just happen in Java, it happens in C++ stuff too, and it can even be the throughput bottleneck for data going from the right kind of disk to the network -- that's why zero-copy I/O exists.

elteto• 14 years ago

Yikes... using pointers in Java, definitely not the best idea. Like other poster said this is all meaningless if you are just blocking waiting for network IO, and there are some pretty fast serialization frameworks around: https://github.com/eishay/jvm-serializers/wiki/Staging-Resul...

mjpt7773• 14 years ago

Most of those frameworks you reference are much greater than 1 microsecond round trip which is the same ballpark as good network IO. For IPC this is much less. I operate in the financial low-latency space where this matters.

specialist• 14 years ago

Fastest Java solution I've seen to date:

kryo - Fast, efficient Java serialization and cloning

http://code.google.com/p/kryo/

It'd be fun to see how kryo stacks against native C++.

ShabbyDoo• 14 years ago

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.

Native C/C++ Like Performance For Java Object Serialisation

Related Stories