A final possible step in the optimization process for our puzzle-solving
program is the use of low-level Java code optimization idioms. We're
not manipulating any strings in our application, so applying the
idiom is useless. We could try to avoid the method call overhead for
getters and setters by replacing those getters and setters with direct
member access. However, this clearly degrades the quality of our code
and tests show that this hardly generates any speedup at all. The same
is true for the use of
final methods. By declaring our methods as
we avoid dynamic binding and allow the Java virtual machine to use more
efficient static binding. But alas, this does not produce any
noticeable speedup. Also, the use of the
-O optimization switch of the Java compiler does not produce any real performance increase.
A slight execution speedup can still be obtained by improving the implementation of the
prune() method. The code in Listing 7 always makes a call to the recursive
getIslandSize() method, even if the board cell is already processed or is not empty. If we proactively do these checks before invoking
getIslandSize(), we gain about 10 percent.
As is clear from this discussion, low-level optimizations result in very small performance increases. This, combined with the fact that some of these optimization techniques deteriorate the quality of your code, makes the use of low-level optimizations unappealing.