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
finalattributes 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.