views:

333

answers:

5

In my project there are some 'Prototype' factories that create instances by cloning a final private instance.

The author of those factories says that this pattern provides better performance than calling 'new' operator.

Using google to get some clues about that, I did not found anything relevant. Here is a small excerpt found in a javdoc from an unknown project

Sadly, clone() is rather slower than calling new. However it is a lot faster than calling java.lang.Class.newInstance(), and somewhat faster than rolling our own "cloner" method.

For me it's looking like an old best practice of the java 1.1 time. Does someone know more about this ? Is this a good practice to use that with 'modern' jvm ?

+11  A: 

Absolutely, this type of practice is completely obsolete. The Java virtual machine has improved drastically since then. Object creation is extremely cheap. Another related practice, Object Pooling, is also obsolete because the cost of Object creation and cleanup is so much more efficient now. For some cases it might be useful (Jon Skeet gives some good examples here), but in no way should it be part of a base framework library such as this.

I would suggest finding some new libraries and/or a new project to work on ;-)

Check out this class article Java Urban Performance Legends for some more insight.

Mark Renouf
Good article reference.
Steve B.
Thanks for the link, I knew there were something wrong with this design but I needed some 'academic' proofs !
Guillaume
I just have to mitigate the answer: this is not valide for android dev: google best practice promotes the clone / pooling usage vs the object creation
Guillaume
Yes, Android is written with Java, but is not really Java, so that's technically correct. It's more accurate to say that object pooling is no longer necessary for Sun's HotSpot JVM (and others like it). Dalvik is it's own animal, and Object creation and GC can be expensive and painful on resource constrained devices, so always follow the best practices of your target platform/JVM. (Though, I wish this weren't the case, it is for now.)
Mark Renouf
+1  A: 

No.

Oh, I need more characters for an answer. So let me expand and say that such micro-optimization is inappropriate unless there is a problem, and if there is, then you should be in a position to measure if it makes things better.

Yishai
+1  A: 

Gee. That's one of the worst idea I've ever heard.

Don't do weird things. Even if you have measured and see some apparent improvement (well, zero chance of that in this case), think a long time before doing it.. Who knows it will be fixed in the next JVM. Then you are left with some weird piece of code that performs worse, is difficult to read, and some bugs because of that.

I mean, it's not like people developing the JVM are idiots! Use new!

I think you should get rid of that strange piece of code.

Enno Shioji
+2  A: 

As others have said this is an antiquated practice. It is an outdated pattern that unfortunately with the newer JVMs will add more bloat to the code without giving a performance boost.

I wish I still had the code so I could share, but a while back I did a simple performance test of this pattern vs using the 'new' operator and I found that using the 'new' operator was at worst at least as fast as this pattern, and at best faster and more efficient. There may be some edge case my test didn't cover where this could still be a valid approach, but in general I would say avoid this pattern.

Another note though, I would suggest you not worry about this too much if it is present in an existing code base. But also I wouldn't write new code to extend this pattern for more parts of your project, unless not doing so would hurt the clarity and consistency of your code base- at which point you should evaluate whether or not it would be smart in the long run to refactor this code out of your project. By 'smart' I mean, would refactoring this code out of your project save time in the future on development and debugging > the amount of time necessary to refactor this out.

instanceofTom
A: 

Do you think when we are making 1000 objects using new() in a loop will still be faster than making 100 objects in a loop using clone()?

ASC
well, it's depend a lot of what is your JVM, what is doing your new and what is doing the clone... BTW, this is not an answer... you deserve a negative vote, but I'll be magnanimous as you are a real beginner here.
Guillaume