Maintainability

Maintainability optimization is performed to help make code more manageable in the future. This type of optimization is usually geared toward the structure and organization of code, rather than modifications of the algorithms used in the code. In general, maintainability optimization involves a programmer studying the code at large and making changes to help other programmers understand and modify the code in the future.

If you haven't guessed, maintainability optimization doesn't rank very high on the list of important optimizations used by game developers. It's still important to organize your code and enforce some structure, but just don't let maintainability optimization become an overriding concern.

Size

Another popular optimization is size optimization, which involves making changes to code that result in a smaller executable class file. The cornerstone of size optimization is code reuse, which comes in the form of inheritance for Java classes. Fortunately, good OOP design strategies naturally favor size optimization, so you will rarely need to go out of your way to perform this type of optimization. For example, it's just good design practice to put code that is reused a few times in a method. In this way, most size optimizations naturally take place during the initial code development.

Although not entirely crucial, size optimization can't be completely ignored in regard to Java game programming. This is because the size of your compiled Java classes will directly impact the amount of time it takes your game to load and initially execute. If, however, you leverage as much of the standard Java API code as possible and reuse code by deriving from other classes, you're probably doing enough for the cause of reducing class size.

Speed

And now, introducing the real subject of toChapter's lesson: speed optimization. Speed optimization is without a doubt the most important aspect of game development after the game is up and running correctly. Speed optimization includes all the techniques and tricks used to speed up the execution of code. Considering the performance problems inherent in Java, speed optimization takes on an even more important role in Java than in other languages such as C and C++. Because the Java compiler has the last word on how code is generated, most speed optimizations will be performed with the compiler in mind.

The rest of toChapter's lesson focuses on issues of speed optimization and how to get the best performance out of your Java code. At times, you will sacrifice the other areas of optimization for the sake of speed. In most cases, this sacrifice is entirely acceptable, even expected, because the organization of the code and size of the executable classes won't matter much if your game is too slow to play.

Optimizing with the JDK Compiler

All optimizations begin and end with the Java compiler. If you don't understand the compiler, you're largely guessing at which optimizations will have a positive effect on your code. So let's take a look at the JDK compiler and see what role it plays in turning out speedy Java bytecodes.

A bytecode is a Java term referring to the intermediate processor-independent code generated by the Java compiler. Bytecode executables (classes) are interpreted by the Java runtime system.

The JDK compiler (javac) includes a switch for generating optimized Java bytecode executables: -O. In release 1.0 of the JDK, this switch results in only two optimizations taking place: inline methods and exclusion of line numbers. The first of these optimizations is the only one that affects the speed of the executable bytecode; final, static, and private methods are inlined by the compiler, resulting in less method call overhead.

Method inlining is the process of replacing each call to a method with the actual method code. Inlining can often increase the size of the resulting class file, but it can help improve performance.

The second optimization performed by the JDK compiler results in the exclusion of line number information from the executable class file. This is a size optimization and does nothing in terms of helping speed up the code.

As you can see, the JDK compiler does little for you in regard to optimization. This basically means that you need to plan on doing a lot of optimization by hand. A future release of the JDK should (I hope) improve this situation, but you can't afford to stand around waiting for miracles-you've got games to write!

Costs of Common Operations

Now that you understand what the JDK compiler does (or doesn't do) for you in regard to optimization, it's time to focus on the Java runtime system. By examining the runtime system, you can get an idea of how fast certain types of code run and make smarter decisions about the way you write Java code. What do I mean by examining the runtime system? Well, I mean running different types of code and timing each type to see how the speeds match up. This operation gives you a very realistic look at how code differs in terms of execution speed and consequently gives you a place to start making appropriate code optimizations.

The speed of an operation is often referred to as the cost of the operation. Code optimization can almost be likened to accounting, in which you try to keep from blowing a performance budget with your code costs. As if optimization weren't tedious enough as it is, I had to make a reference to accounting! Anyway, Jonathan Hardwick performed a very neat analysis on the cost of common Java operations on various systems, the results of which I've included in Tables 20.1 through 20.3. These tables contain approximate times in microseconds for common Java operations. Incidentally, the systems used to perform the cost analysis were a Sun Sparcstation 5 running Solaris, an AMD 486 DX4-120 running Windows 95, and an AMD 486 DX4-120 running Linux 1.2.13.

In terms of speed optimization, cost refers to the speed required to perform an operation.

Table 20.1. The costs of Java variable accesses.

Table 20.2. The costs of increment with Java data types.

Table 20.3. The costs of miscellaneous Java operations.

These tables point out lots of interesting information regarding the performance of Java code. From Table 20.1, it's readily apparent that method variables are more efficient to use than instance variables. Furthermore, you can see that array element assignment is slower than method variable assignment due to the fact that Java performs bounds checking operations whenever an array element is accessed. Keep in mind that this table isn't meant as an argument to get rid of all your class member data. Rather, think of it as providing insight into making those decisions in which the design could go either way.

Table 20.2 shows timing data relating to the use of the standard Java data types. As you might have expected, the two 32-bit data types, int and float, showed the best performance because the tests were performed on 32-bit systems. It is interesting to note that the performance difference between using an int over a byte, short, or long is much more significant than for using a float over a double.

Even though the floating-point types show comparable performance to the integer types, don't be misled about using integer math over floating-point math. This timing table reflects only an increment operation, which is much different than more complex operations performed in the context of a game. Integer math is much more efficient than floating-point math. So use the table as a measure of the relative speeds among integer types, and then try to use integer math throughout your code.

Table 20.3 focuses on a few miscellaneous operations that are worth thinking about. First, it shows the high cost of creating an object. This should serve as an incentive to eliminate the creation of temporary objects within a loop where the creation occurs over and over. Rather, you can place the temporary object above the loop and reinitialize its members as needed inside the loop.

Table 20.3 also shows the dramatic performance costs of using a normal method versus a synchronized method. Even though synchronization is very important in multithreaded programming, this should be some encouragement to minimize the usage of synchronized methods in games.

Finally, Table 20.3 shows you how using the standard Java math methods can sometimes be a burden. Even something as simple as taking the absolute value of a number imposes much greater performance costs when you call the Math.abs method, as opposed to inlining the equivalent code yourself.

Isolating Problem Code

The biggest mistake you can make in regard to optimizing your game code is trying to optimize all the code. Being smart about what code you attack is crucial in not spending years trying to improve the performance of your game. More important, it's a well-established fact that a relatively small portion of code is usually responsible for the bulk of the performance drain. It's your job to isolate this code and then focus your optimization efforts accordingly.

Fortunately, isolating problem code isn't all that difficult if you use the proper tools. The most useful tool in finding bottlenecks in your code is a profiler. A profiler's job is to report on the amount of time spent in each section of code as a program is executing. The Java runtime interpreter has an undocumented built-in profiler that is easy to use and works pretty well. To use the runtime interpreter profiler, simply specify the -prof option when using the interpreter, like this:

java -prof Classname

Classname is the name of the class you want to profile. Of course, this technique doesn't work too well for applets, because they must be run within the context of the applet viewer tool or a browser. Fortunately, you can use the profiler with applets by altering the arguments to the interpreter a little, like this:

java -prof sun.applet.AppletViewer Filename

In this case, Filename is the name of the HTML file containing a link to your applet. When you finish running the applet, the interpreter will write a file named java.prof to the current directory. This file contains profile information for the applet you just ran.

To get an idea of what kind of information the Java profiler generates, check out Listing 20.1, which contains a few lines of profile information generated for the Traveling Gecko sample game. I've cleaned up the listing a little by hand just to make it easier to read.

Listing 20.1. A partial profile listing for the Traveling Gecko sample game.

count callee                              caller          &nbs p;                 time
25261 java/util/Vector.size()             SpriteVector.testCollision(        19
22780 java/util/Vector.elementAt(I)       SpriteVector.testCollision(        38
20258 java/awt/Rectangle.intersects()     Sprite.testCollision(LSprite;)     56
20258 Sprite.getCollision()               Sprite.testCollision(LSprite;)     4
20258 Sprite.testCollision(LSprite;)      SpriteVector.testCollision(        102
10360 Sprite.getPosition()                SpriteVector.update()V             2
4075  java/lang/Object.<init>()           java/awt/Rectangle.<init>(IIII)    0
3800  sun/awt/image/Image.getImageRep(II) sun/awt/win32/Win32Image.getImage  60

As you can see, the profile information is broken down into four columns. The first column specifies how many times a particular method was called, and the second column states the name of the method. The third column specifies the calling method, the one that invoked the method in question. Finally, the fourth column specifies the relative amount of time spent in the method during each call. The larger this number is, the more costly the method.

You can easily use this information as a guide to determine the code on which to focus your optimization efforts. The methods appearing at the top of the list should receive much greater attention, because they are being called far more times than methods farther down in the list. Making small performance gains in a method that is being called 20,000 times will have a much greater impact than speeding up a method that is called only a couple of hundred times. The cool thing is that you can try different optimizations and then run the profiler again to see whether the relative times have changed. This is a very practical, if somewhat time-consuming, way to make great strides in speeding up your games.

Optimization Techniques