As an additional effort to measure the performance impact of the introduction of interception ability, we have measured the execution time for the Java compiler to translate the test program to Java bytecodes. The averaged execution times are presented in Table 5.
These are the total execution times of the compile test for each configuration. They were used to calculate the lines compile in Table 3 and Table 4.
(times are in seconds)
These are the times spent on JIT compilation during the execution of the compile test. They were used to compute the values in the compile-JIT line of Table 4.
(times are in seconds)
These are the differences between total execution time (compile) and JIT compilation time (compile-JIT), i.e., the times spent on execution of the JIT compiled code. They were used to compute the values in the compile-diff line of Table 4.
(times are in seconds)
On short-running applications like this, most of the time is spent on virtual machine initialization and JIT compilation, not on running the application itself. The virtual machine start-up, for example, involves executing very large array initialization methods, whose JIT-compilation wastes a lot of memory and CPU cycles, because these methods are executed only once.
Although a complex program, involving several similar classes, is being compiled, Table 6 shows that more than 50% of the total time was spent on JIT-compiling Java Core classes and the Java compiler itself. Therefore, the actual overhead in execution time, at least for long-running applications, is much smaller.
Table 7 presents the differences between the total time and the JIT-compilation time, that represents the time spent on running the actual application, i.e., the compiler. Long running applications, that repeatedly execute the same methods, should present a reflection overhead similar to the relative overhead of this table.