/ PERFORMANCE, SOFTWARE ENGINEERING

Performance cost of reflection

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):

Test results

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.
Nicolas Fränkel

Nicolas Fränkel

Nicolas Fränkel is a Developer Advocate with 15+ years experience consulting for many different customers, in a wide range of contexts (such as telecoms, banking, insurances, large retail and public sector). Usually working on Java/Java EE and Spring technologies, but with focused interests like Rich Internet Applications, Testing, CI/CD and DevOps. Currently working for Hazelcast. Also double as a teacher in universities and higher education schools, a trainer and triples as a book author.

Read More