In Java, it’s widely admitted that reflection - usage of the java.reflect API, comes at a high cost in terms of performance. Older Java versions had huge performance overhead, while it seems that newer versions bring it in the acceptable range. But what does "acceptable" really mean?

This is the question I asked when commenting on a performance review that advised to replace code based on reflection by standard code. As many of our decisions are not based on facts but on beliefs, I decided to perform some tests to get metrics in Java 8.

Testing protocol In order to get realistic metrics through an unchallenged protocol, I used the excellent JMH testing framework. JMH has several advantages, among others: An existing Maven artifact is readily available

Methods to benchmark have only to be annotated with @Benchmark

It handles the warming up of the JVM

It also handles the writing the results on the console Here’s a JMH snippet: @Benchmark public void executePerformanceTest () { // Code goes here } JMH will take care of executing the above executePerformanceTest() and taking care of measuring the time taken.

The code To highlight the cost of reflection, let’s check the difference between the time needed to access attributes with reflection and to call simple getters without. // With reflection Field firstName = clazz . getDeclaredField ( "firstName" ); Field lastName = clazz . getDeclaredField ( "lastName" ); Field birthDate = clazz . getDeclaredField ( "birthDate" ); Field . setAccessible ( new AccessibleObject [] { firstName , lastName , birthDate }, true ); firstName . get ( person ); lastName . get ( person ); birthDate . get ( person ); // Without reflection person . getFirstName (); person . getLastName (); person . getBirthDate ();

Checking possible optimizations I was wondering if immutable data structures were compiled into optimized bytecode that could decrease the performance overhead of reflection. Thus I created the same basic data structure in two-different ways: One mutable with a no-args constructor and setters

One immutable with final attributes and constructor initialization

Results Running the tests on my machine yields the following results: # Run complete. Total time: 00:26:55 Benchmark Mode Cnt Score Error Units BenchmarkRun.runImmutableWithReflection thrpt 200 2492673.501 ± 37994.941 ops/s BenchmarkRun.runImmutableWithoutReflection thrpt 200 26499946.587 ± 242499.198 ops/s BenchmarkRun.runMutableWithReflection thrpt 200 2505239.277 ± 27697.028 ops/s BenchmarkRun.runMutableWithoutReflection thrpt 200 26635097.050 ± 150798.911 ops/s For table-minded readers: Non-reflection Reflection Mutable 26,635,097.050 ± 150,798.911 2,505,239.277 ± 27,697.028 Immutable 26,499,946.587 ± 242,499.198 2,492,673.501 ± 37,994.941 And for bar chart interested readers (note the scale is linear):

Conclusion Whatever the way results are displayed, it will take about 10 times more to access a field with reflection than without…​ on my machine. My guess is that this can be extrapolated to be true on any machine. There’s a corollary conclusion: whatever you think holds true at a given time, you should always do some fact-checking to ensure a solid foundation for your decisions.

The complete source code for this post can be found on Github