Professional Documents
Culture Documents
Demetrius L. Davis
Number of iterations
250 1000 3500
Array size Array size Array size
250 1000 10000 250 1000 10000 250 1000 10000
Heapsort (ms)
Java 40 40 50 140 140 140 400 400 400
JNI 30 30 110 30 60 390 60 150 1310
FFT (ms)
Java 741 4577 49290 2924 18286 197154 10165 63942 689381
JNI 742 4576 49661 2904 18196 197805 10234 63912 694048
Clearly, the most telling results from the Heapsort runs can be count increases, the JNI program further widens the performance
seen in Figures 4, 5, and 6. Unlike the iteration count-based line gap when the array elements do not exceed 1000.
charts, the bar charts view the data according to the array sizes.
The nearly identical results for the pure Java implementation At some point beyond 1000 elements, the JNI implementation
further the assertion that the iteration count plays a more takes an enormous performance hit. The cause of the sudden
significant role than the array size. While the pure Java degradation in execution speed is likely attributable to memory
implementation shows little to no variation, the JNI limitations of the test computer than to an inherent lack of
implementation yields a pronounced curve as the array size scalability of JNI. Nonetheless, the figures in Appendix A
increases. Up to 1000 integers, the JNI implementation expose an obvious shortcoming of JNI: heavyweight objects or
outperformed the pure Java version; actually, as the iteration large arrays of primitive data types have a noticeably adverse
effect on the application performance.
Time (ms)
150 150
400
100 100
200
50 50
- - 0
250 1000 3500 250 1000 3500 250 1000 3500
Iteration count Iteration count Iteration count
Figure 1 – Heapsort (250 elements) Figure 2 – Heapsort (1000 elements) Figure 3 – Heapsort (10000 elements)
350 1200
100
300
1000
80
250
Time (ms)
Time (ms)
Time (ms)
800
60 Java 200 Java Java
600
JNI 150 JNI JNI
40
400
100
20
50 200
0 0 0
250 1000 10000 250 1000 10000 250 1000 10000
Array size Array size Array Size
Figure 4 – Heapsort (250 iterations) Figure 5 – Heapsort (1000 iterations) Figure 6 – Heapsort (3500 iterations)
This research effort has uncovered several interesting findings.
Discrete Fast Fourier Transform (FFT) First, JNI is definitely a viable option for handling algorithms
The results from the execution of the FFT algorithm offer that manipulate a small to moderate-sized set of primitive data
additional insight into the differences between a pure Java and a types. In such cases, the time required to “wrap” a native routine
C++ routine implemented via the JNI. The FFT routine involves within a JNI framework is minimal compared to transcribing the
more mathematical computations and takes a sizeable amount of native routine into a comparable Java version. The consistency
time to execute as compared to the Heapsort algorithm. This recorded by the pure Java implementation indicates that, as the
disparity served two purposes: the two Java programs executed a need for larger sized or a larger number of elements arises, a pure
more computationally intensive algorithm and consequently, each Java re-implementation of the native code routine is
implementation to handle extensive math computations was recommended.
sufficiently tested. Secondly, the overall performance of either Java implementation
The range of execution times between the Heapsort and FFT runs is greatly influenced by the efficiency and performance of the
were significant. Nonetheless, there is profound symmetry underlying algorithm. Performance can be markedly improved if
between the execution times of the two algorithms (see Table 2). an algorithm is optimized for performance and a small memory
Moreover, the execution times between the Java and JNI footprint. Such constructs as nested loops, recursion, and
implementations of the FFT algorithm are eerily similar. Unlike excessive object instantiations will result in a drastic decrease in
the highly efficient Heapsort algorithm, the necessary processing response times. This assertion is supported by the data collected
time for the FFT algorithm outweighed any overhead impact from the Heapsort algorithm runs. The efficiency of the Heapsort
generated by JNI function calls. As suspected, the recorded times algorithm, which executes in less than O(n log n) time, is a major
of a less-than-efficient algorithm reflect more of the algorithm contributor towards the relatively fast times recorded in Table 1.
performance and efficiency than the performance of the Lastly, the performance of the pure Java implementations as the
programming platform. iteration count increases is amazingly linear. In the executions of
In addition to the similarity in the execution times, the rate of the Discrete Fast Fourier Transform algorithm, for array
execution is also nearly identical throughout every run and containing 250 integers, the algorithm maintained a 2.9-
iteration count grouping. Regardless of array size or number of millisecond average over all three iteration count groups. The
iterations, every FFT calculation averaged 2.9 milliseconds. This Heapsort algorithm registered extremely minimal variations.
form of consistent performance indicates a high probability that This conclusion establishes a pure Java implementation as a
the implementation, whether pure Java or part Java, will not lower risk option when the variable parameters of the application
adversely affect the scalability of this type of algorithm. are not readily known.