Is there a penalty for calling newInstance() or is it the same mechanism underneath? How much overhead if any does newInstance() have over the new keyword* ?
*: Discounting the fact that newInstance() implies using reflection.
A:
Be wary of microbenchmarks, but I found this blog entry where someone found that new was about twice as fast as newInstance with JDK 1.4. It sounds like there is a difference, and as expected, reflection is slower. However, it sounds like the difference may not be a dealbreaker, depending on the frequency of new object instances vs how much computation is being done.
Eddie
2009-03-15 02:19:21
Reflection has gooten faster with each release of Java.
TofuBeer
2009-03-15 03:18:52
Yes, indeed, which is why I mentioned use of 1.4 in the benchmark I found. I'm sure that newInstance is still slower, but I'd be surprised if it were a huge difference.
Eddie
2009-03-15 03:32:10
Calling setAccessible(true) on the Constructor should make it slightly faster (but make sure still secure). Of course, I'd suggest avoiding reflection if possible in any case.
Tom Hawtin - tackline
2009-03-16 11:41:54
A:
It is likely that any overhead newInstance() may have will be so insignificant it does not matter if you use it. Though if it comes down between which is faster new is probably the faster one.
Anton
2009-03-15 02:19:22
+5
A:
In a real world test, creating 18129 instances of a class via "Constuctor.newInstance" passing in 10 arguments -vs- creating the instances via "new" the program took no measurable difference in time.
This wasn't any sort of micro benchmark.
This is with JDK 1.6.0_12 on Windows 7 x86 beta.
Given that Constructor.newInstance is going to be very simlilar to Class.forName.newInstance I would say that the overhead is hardly anything given the functionality that you can get using newInstance over new.
As always you should test it yourself to see.
TofuBeer
2009-03-15 03:17:17
Check out http://www.ibm.com/developerworks/java/library/j-jtp02225.html ... these sorts of benchmarks are very difficult to get right due to the dynamic way that code is compiled/optimized by the JVM.
Eddie
2009-03-16 15:06:55