Serialization Optimization Pitfalls

You might want to check "JBoss Serialization" as well (led by Clebert Suconic):
labs.jboss.com/portal/serialization/

From the project page:

We (java developers) have accepted over the years java.io.ObjectInputStream and java.io.ObjectOutputStream being slow when dealing with writeObject operations.
We then started using Externalizable objects as a faster approach for serialization, but even that way was slow when using writeObject operations inside externalizable classes.
Recently we discovered that most of the problems in JavaSerialization are related to static synchronized caching, what causes CPU spikes and also diminishes scaling capabilities.
With JBossSerialization we have done internal benchmarks and we have realized at least 2 times faster serialization with this library. These benchmarks are commited into our CVS repository (as testcases) and they are publicly available.

The main feature in JBossSerialization besides performance, is Smart Cloning
Smart cloning is the capability of the reuse of final fields among different class loaders doing exactly what serialization does, without the need of convert every field into a byteArray.
This approach is at least 10 times faster than using serialization over a byte array.

Using JBossSerialization is very simple:
Instead of instantiating ObjectOutputStream and ObjectInputStream, you would instantiate JBossObjectInputStream and JBossObjectOutputStream (org.jboss.serial.io). You will also have to add jboss-serialization.jar to your classpath.
Everything from the specification is then respected. The only exceptions are:
I - We are using a different protocol as we are focusing in performance (e.g. Smart Cloning ), so that requires the object being serialized and deserialized with JBossSerialization classes.
II - You can serialize classes that are not implementing Serializable, although that's a feature as you can enable that checking.

It works on Java 1.4.2 or JVM 1.5

If you run a multi-threaded microbench you'll find that the SoftReferenceCache mentioned above becomes a point of contention because it is accessed in a synchronized block. Performance starts to degrade after like 50-100+ threads because of the contention. Replacing this cache with a ConcurrentHashMap (i used the oswego one when I did my benchmarks) removes this contention and give you better scalability.

Bill

Recent 1.5.0 updates (and 1.6.0) have ditched ye olde SoftCache for a new concurrent-friendly cache. I'm not going to suggest that java.io has respectable performance, but it's an improvement.