Speedup techniques

Now

that the critical region has been isolated, you can apply two types of

Generic
approaches

An

effective generic speedup is to redefine the program in a more practical way.

For example, in

[14], Bentley describes Doug McIlroy’s representation of the English

language with a novel data depiction that enabled him to produce a remarkably

fast, compact spelling checker. In addition, choosing a better algorithm will

probably give a bigger performance gain than any other approach, particularly

as the size of the data set increases. For more of these generic approaches,

see the general book listings [12-19] at the end of this appendix.

Language
dependent approaches

To

put things in perspective, it’s useful to look at the time it takes to

perform various operations. So that the results are relatively independent of

the computer being used, they have been normalized by dividing by the time it

takes to make a local assignment.

Using

present systems (such as Pentium 200 pro, Netscape 3, and JDK 1.1.5), these

relative times show the extraordinary cost of new objects and arrays, the heavy

cost of synchronization, and the modest cost of an unsynchronized method call.

References [5] and [6] give the Web address of measurement applets you can run

on your own machine.

General
modifications

Here

are some modifications that you can make to speed up time-critical parts of

your Java program. (Be sure to test the performance before and after you try

them.)

Specific
situations

:

The

concatenation operator + looks innocent but involves a lot of work. The

compiler can efficiently concatenate constant strings, but a variable string

requires considerable processing. For example, if

and

are

variables:

this

requires a new

,

appending arguments, and converting the result back to a

with

.

This costs both space and time. If you’re appending more than one

,

consider using a

directly, especially if you can repeatedly reuse it in a loop. Preventing the

creation of a new

on each iteration saves the object creation time of 980 seen earlier. Using

and the other

methods is usually an improvement. When feasible, character arrays are even

faster. Also notice that

is costly because of synchronization.

:

In the JDK interpreter, calling a

method is typically 10 times slower than calling an unsynchronized method. With

JIT compilers, this performance gap has increased to 50 to 100 times (notice

the timing above shows it to be 97 times slower). Avoid

methods if you can – if you can’t, synchronizing on methods rather

than on code blocks is slightly faster.

:

It takes a long time to create an object (the timing above shows 980 assignment

times for a new

,

and 3100 assignment times for a small new array), so it’s often worth

saving and updating the fields of an old object instead of creating a new

object. For example, rather than creating a new

object in your

method, you can declare it an instance object, initialize it once, and then

just update it when necessary in

.

See also Bentley,

p. 81 [15].

:

You should only throw exceptions in abnormal situations, which are usually

cases in which performance is not an issue since the program has run into a

problem that it doesn’t normally expect. When optimizing, combine small

–

blocks, which thwart compiler optimization by breaking the code into small

independent sections. On the other hand, be careful of sacrificing the

robustness of your code by over-zealous removal of exception handling.

The

standard

class in Java 1.0 and 1.1 requires casting and costly synchronization (570

assignment times). Furthermore, the early JDK library doesn’t

deliberately choose prime number table sizes. Finally, a hashing function

should be designed for the particular characteristics of the keys actually

used. For all these reasons, the generic

can be improved by designing a hash class that fits a particular application

Note that the

in the Java 1.2 collections library has much greater flexibility and

isn’t automatically

.

Java compilers can inline a method only if it is

,

,

or

,

and in some cases it must have no local variables. If your code spends a lot of

time calling a method that has none of these modifiers, consider writing a

version that is

.

:

Use buffers wherever possible, otherwise you can end up doing I/O a single byte

at a time. Note that the JDK 1.0 I/O classes use a lot of synchronization, so

you might get better performance by using a single “bulk” call such

as

and then interpreting the data yourself. Also notice that the Java 1.1

“reader” and “writer” classes were designed for

improved performance.

:

Casts

take from 2 to 200 assignment times. The more costly ones require travel up the

inheritance hierarchy. Other costly operations lose and restore capabilities of

the lower level constructs.

Use clipping to reduce the amount of work done in

,

double buffering to improve perceived speed, and image strips or compression to

speed downloading times.

from JavaWorld and

from Sun are two good tutorials. Remember to use high-level primitives;

it’s much faster to call

on a bunch of points than looping with

.

If you must draw a one-pixel-wide line,

is faster than

.

:

Use classes from the Java API when they offer native machine performance that

you can’t match using Java. For example,

is much faster than using a loop to copy an array of any significant size.

:

Sometimes API classes do more than you need, with a corresponding increase in

execution time. For these you can write specialized versions that do less but

run faster. For example, one application that needed a container to store many

arrays was speeded by replacing the original

with a faster dynamic array of objects.

Other
suggestions

• Move
  repeated constant calculations out of a critical loop, for example, computing
  buffer.length
  for a constant-size
  buffer.
• static
  final
  constants
  can help the compiler optimize the program.
• Unroll
  fixed length loops.
• Use
  javac’s optimization option,
  -O,
  which optimizes compiled code by inlining
  static,
  final,
  and
  private
  methods. Note that your classes may get larger in size (JDK 1.1 or later only
  – earlier versions might not perform byte verification). Newer
  just-in-time (JIT) compilers will dramatically speed the code.
• Count
  down to zero whenever possible – this uses a special JVM byte code.
  

|

|