Auto_commit should be avoided like the plague. And not only as performance issue. Think about concurrency and atomicity?

Have you tried to run the benchmark without -server? If yes, what was the outcome?

I suggest runing the test for at least 10,000 times, twice and discarding the first run. I also suggest you run what you believe is the fastest first, to prevent earlier benchmarks from warming up the JVM and making later ones appear faster.

You can improve reflection performance by disabling the security check which is performed on every call. i.e. setAccessible(true) even if its public, which stops it checking its public.

You could also benchmark using POJO’s without accessor methods. Fields via reflection can be faster, esp for primitive typed fields, and if this isn’t fast enough you can try the *Unsafe* class which can be 2-3x faster again. The Unsafe class is approriately named, BTW.

So both Spring and WebSphere recommend you to use the UOW instead. For example if you use the standard JPA transaction manager things like PROPAGATION_REQUIRES_NEW suspend/resume won’t work, but with UOW IBM supports it.

The same bench with ITERATIONS=1000000 and THREADS=1 will “show” reflection performance 30 times slower than normal (which is currently closer to reality).

IMHO, this is not close to reality. Multithreading and concurrency are very real and my clients need solutions that scale, also with regards to concurrency.

But, I’ve ran the test with multiple variations of thread counts and they result in pretty much the same numbers.

I know the claim that setAccessible(true) has a positive effect on performance. This is also pretty obvious when you look at the source code of Method and Constructor. But… in my experiment I didn’t see any difference in performance, not even under high contention. I assume the JIT inlines the invoke() call and generates a fast-path for the common case.
So, I guess with modern VM’s we can put the setAccessible(true) optimization in the “performance myths” bucket.

About the primitives, dunno how to use reflection with primitives. :S

You’re right about the Varargs. I forgot them on the Method.invoke() calls. (I think the interchangeability of arrays and varargs was a big design flaw. See Arrays.asList() for an example) A simple test where I (re)used an array to hold the parameters, seemed to give me a 25% improvement. Thank you for that one.

I agree with your JIT argument.

The same bench with ITERATIONS=10 will “show” reflection performance being very close to normal.
The same bench with ITERATIONS=1000000 and THREADS=1 will “show” reflection performance 30 times slower than normal (which is currently closer to reality).

Microbenchmarking is difficult, and often the conclusions taken from those is wrong.
In your case too many factors are tested at the same time, making the result benchmarks of not only reflection, but all those as well, such as:
- synchronization performance, as reflection is synchronized in Method.invoke for instance, you’ll get better reflection performance in your bench by NOT sharing the cached Method instance between the threads.
- Integer autoboxing is used in the reflection case, involving more object creation (only 128 first Integer objects are cached) and garbaging. This overhead only occurs with primitive types.
- varargs are used in all operations (as you showed with constructor), making a lot of Object[] creation & garbage, you can optimize that away as well

As finbar said, setAccessible(true) makes a huge difference for reflection, and brings reflection calls times to only 200% of regular calls.
It also bypasses security checks, and might be prevented by a lot of real-world apps java security policies.

But my final word about reflection performance is that it prevents JIT optimizations.
It might not be obvious in your case, but do the same test keeping only the getter in the loop, the normal case will get jit’ed, not the reflection one, and even with all our efforts (setAccessible included), there’ll be a LARGE difference between the 2 tests

Have fun !
Microbenchmarking Java seems a neverending task to me, but I do keep trying