Skip to content

MattHicks.com

Programming on the Edge

Menu
Menu

Fastest Deep Cloning

Posted on May 22, 2008 by mhicks

I recently needed to do deep cloning of my Java objects and began to do the old-school style I’ve used for years: Use ObjectOutputStream and ObjectInputStream to do a “poor-boys” deep clone. However, the performance of this on large Objects is absolutely awful not to mention the amount of memory and CPU it takes to accomplish this. Even if I could get past all of that, the fact that every single Object in the chain MUST implement Serializable just pushed me over the edge…

I thought to myself, “Surely someone else realizes how dumb this is and has a better solution that having to implement Cloneable on everything”, but alas, searching online didn’t return much other than explanations how to use Serialization to do deep cloning and a little tutorial on increasing the performance on Serialization cloning:

http://javatechniques.com/blog/faster-deep-copies-of-java-objects/

I found that interesting, but it really didn’t provide that great of a performance gain, and still didn’t overcome the other issues, so I set out to make a rounder wheel. Perhaps it’s the years of Reflection I’ve got hammered into me, or just the fact I think Reflection is awesome, but I turned to my old friend for a faster solution. It really is ironic, since so many people refuse to use Reflection because of performance reasons that I would turn to Reflection to increase performance, but lets see how this goes. 🙂

So, I took the benchmark test that is referenced in the article above and decided to apply it to my own test using Reflection and see the performance difference. The difference is staggering. After modifying the benchmark to do better timing (System.nanoTime instead of System.currentTimeMillis and a couple other tweaks) I bumped up the iterations to 100 and got the following results:

Unoptimized time (standard Serialization): 13,518 milliseconds

Optimized time (the tutorial Serialization): 12,941 milliseconds

Reflection time (my happy little test): 139 milliseconds

Yes, I did expect the performance to increase, but about 100 times faster is a startling increase in performance. So I bumped up the test another digit to see how well it scaled:

Unoptimized time (standard Serialization): 125,754 milliseconds

Optimized time (the tutorial Serialization): 121,434 milliseconds

Reflection time (my happy little test): 1,359 milliseconds

Okay, this seems to scale at least as well as the alternative and doesn’t require the objects to be Serializable. The only problem is that there is substantially more code involved to make this work well since there are peculiarities with certain objects (arrays, Maps, etc.) that have to be explicitly handled. To deal with this scenario I created an interface, “Cloner” that has a simple method:

public Object deepClone(Object original, Map<Object, Object> cache) throws Exception;

This is relatively self-explanatory, but the “cache” map is the only really complex part. This is necessary in order to handle cyclical references (ex. ObjectA contains ObjectB that contains a reference back to ObjectA) that would otherwise cause an endless loop until either memory is exhausted, or more commonly the case, a StackOverflowException is thrown. Upon instantiation of an Object I immediately assign the original Object as the key in the cache and the cloned Object as the value in the cache. I check at the beginning of cloning of each Object if a cache reference already exists and if so I re-use that.

The Cloner instances are pre-defined in the CloneUtilities Class in a static Map<Class<?>, Cloner>. This not only abstracts the implementation details of cloning per specific case, but also allow extensibility for anyone that needs to handle special Objects in their own cloning scenarios.

If you’re interested in seeing the final results of this, I have added it to my jCommon project so anyone can use it:

http://commonj.googlecode.com/svn/trunk/src/org/jcommon/clone/

I’ve included several cloning options in the CloneUtilities Class to allow testing between different options. However, it would seem that reflection is significantly faster than any other known alternative (apart from explicitly writing Clonable support in your Objects and providing some extra functionality for deep cloning). There is still a lot to add to this in the long-run, but I believe this is a good start.

Please drop me some feedback if you have any standard Cloner implementations to add.

EDIT: This post has received a lot of traffic and the jcommon project is no longer being hosted at the referenced URL, it can be found here: jcommon on googlecode. You can also find a newer yet less complete version of this in the xjava project: clone package

2 thoughts on “Fastest Deep Cloning”

  1. clix101 says:
    January 4, 2013 at 11:50 pm

    Hi Matt,

    This looks great, and is just what I was looking for.
    However, I can't seem to get the code to run properly?
    I get the same error running after compiling the code from both CommonJ and xJava.
    The first two tests run correctly (I'm currently using the optimised serialised deep clone) but the final clone test, using reflection, throws the error:
    Exception during clone (returning original): [Ljava.lang.Object;
    This happens with the test object created by default in the code and on a custom object.
    I'm using Java 1.6 and Eclipse.
    Any help would be much appreciated!
    Thanks

    Reply
  2. Matt Hicks says:
    January 5, 2013 at 2:25 am

    Unfortunately this is old code and I followed some bad coding practices when I wrote it not throwing a proper exception back. If you change ObjectCloner in xjava on line 44 to say: throw new RuntimeException("Exception during clone", exc);

    That should hopefully give you some more information to understanding why that's failing.

    Reply

Leave a Reply Cancel reply

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

Recent Posts

  • Courio: E-Mail 2.0
  • Scribe 2.0: Fastest JVM Logger in the World!
  • Logging Performance
  • Publicity in Open-Source
  • Play Framework for Scala: An Evaluation

Recent Comments

  1. Luke Hutchison on Multithreaded Unzip?
  2. Luke Hutchison on Multithreaded Unzip?
  3. Unknown on Multithreaded Unzip?
  4. D L on Multithreaded Unzip?
  5. Matt Hicks on Multithreaded Unzip?

Archives

  • March 2019
  • February 2018
  • January 2017
  • June 2016
  • July 2015
  • February 2015
  • December 2014
  • September 2013
  • March 2013
  • February 2013
  • January 2013
  • November 2011
  • December 2010
  • October 2010
  • July 2010
  • June 2010
  • May 2010
  • October 2009
  • August 2009
  • July 2009
  • June 2009
  • May 2009
  • March 2009
  • February 2009
  • September 2008
  • July 2008
  • May 2008
  • March 2008
  • January 2008
  • December 2007
  • September 2007
  • August 2007
  • July 2007
  • June 2007

Categories

  • adobe
  • android
  • apple
  • beans
  • benchmark
  • challenge
  • chat
  • comparison
  • courio
  • eclipse
  • example
  • flex
  • framework
  • games
  • hacks
  • helios
  • html
  • hyperscala
  • ios
  • java
  • javafx
  • javascript
  • jcommon
  • jgn
  • jmc
  • jseamless
  • jug
  • kickstarter
  • learning
  • linux
  • log4j
  • logging
  • mac
  • media
  • mediacenter
  • methodology
  • mobile
  • mythtv
  • nabo
  • open-source
  • opengl
  • opinion
  • personal
  • playframework
  • pojo
  • programming
  • publicity
  • rant
  • raspberrypi
  • review
  • scala
  • scribe
  • script
  • sgine
  • social
  • sudoku
  • sun
  • swing
  • tutorial
  • Uncategorized
  • webframework
  • website
  • windows
  • xjava
© 2025 MattHicks.com | Powered by Minimalist Blog WordPress Theme