Investigating the Performance Impact of Java Reflection

The author revisits the question of whether Java reflection incurs a performance penalty, motivated by a comment on a previous article titled "Deep Dive into Reflection". By systematically measuring execution times for direct method calls, reflective method calls, direct field access, and reflective field access across varying iteration counts, the study quantifies the overhead introduced by reflection.

Test code used for the benchmarks:

public class ReflectionPerformanceActivity extends Activity {
    private TextView mExecuteResultTxtView = null;
    private EditText mExecuteCountEditTxt = null;
    private Executor mPerformanceExecutor = Executors.newSingleThreadExecutor();
    private static final int AVERAGE_COUNT = 10;
    // ... (omitted UI setup code) ...
    private void execute() {
        // Runs the benchmark in a background thread and updates the UI with results.
        // Calls getNormalCallCostTime, getReflectCallMethodCostTime,
        // getNormalFieldCostTime, and getReflectCallFieldCostTime for each iteration.
    }
    private long getReflectCallMethodCostTime(int count) { /* reflective method invocation */ }
    private long getReflectCallFieldCostTime(int count) { /* reflective field access */ }
    private long getNormalCallCostTime(int count) { /* direct method call */ }
    private long getNormalFieldCostTime(int count) { /* direct field access */ }
    private void updateResultTextView(final String content) { /* UI update */ }
}

The benchmark results show that reflection does cause a noticeable performance impact, especially when the number of invocations exceeds about 100. The hierarchy of execution speed (from fastest to slowest) is: direct instance field access, direct method call, reflective instance field access, and reflective method call. The slowdown factor ranges from roughly 1.4× for reflective method calls to over 6× for reflective field access compared to direct instance access.

Further analysis isolates the costly parts of reflection to the Method.getMethod / Class.getDeclaredField look‑ups and the Method.invoke / Field.set operations. Experiments that move the reflective lookup outside the inner loop demonstrate that the lookup itself adds overhead, while the actual invocation or field set also contributes significantly.

Possible reasons for the overhead include runtime safety checks, class metadata resolution, and the transition to native code via JNI for the underlying reflective operations.

To mitigate reflection‑related performance issues, the author recommends limiting the frequency of reflective calls, preferring direct field access over reflective method invocation when possible, and caching reflective objects (Method, Field) if they must be used repeatedly.

In the concluding remarks, the author notes that the tests are not exhaustive and suggests future investigations into native method call costs, the impact of extensive conditional checks, and the effect of class complexity on reflection performance.