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 prov
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.
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.
My tests with DecimalFormat (OpenJDK 8/Windows/JMH 1.19) shows completely opposite image:
Benchmark Mode Cnt Score Error Units
Format.everyTimeCreate avgt 10 9326.967 ± 199.511 us/op
Format.useClone avgt 10 5102.397 ± 72.993 us/op
Format.useGlobalWithTL avgt 10 4605.604 ± 59.000 us/op
Looks like it is not so simple to answer what is perform better.
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.
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.
I have created simple benchmark for class Person
. I am using latest OpenJDK 8:
public class Person {
private String name;
private int age;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public int getAge() {
return age;
}
public void setAge(int age) {
this.age = age;
}
}
And got the following results:
Benchmark Mode Cnt Score Error Units
MyBenchmark.viaClone avgt 10 10.041 ± 0.059 ns/op
MyBenchmark.viaNew avgt 10 7.617 ± 0.113 ns/op
This simple benchmark demonstrates that instantiating new object and setting corresponding properties from source object takes 25% less time than cloning it.