|
The following are suggestions that can be used to design or code Java applications. Java applications which are well designed independent of platforms, will run well on OS/390 and z/OS.
See the following web sites:
In addition, some examples of good design and coding techniques are as follows:
Group native operations to reduce the number of JNI calls.
Consider consolidating transactions or operations to minimize the number of JNI calls needed to accomplish a task. Group native operations to reduce the number of JNI calls. You may want to look at the following JNI example Writing a Simple JNI program on OS/390
Reducing the number of times the JNI overhead needs to be paid will improve performance.
Avoid the costs of object creation and manipulation by using primitive types for variables when prudent. Use primitive types because they are faster than classes that encapsulate types.
Memory can be reduced and variable access times can be improved.
Example:
Currency {
public double amount;
}
double currency_amount;
Writing information to the java console (System.out, System.err and System.in) takes time and resources, and should not be done unless necessary. A good rule of thumb is to never write to the Java console unless required by the application.
If you do need to write to the Java console for debugging purposes, make sure you explicitly test the application on a system with the Java console enabled to verify that all the console output which occurs during normal processing has been turned off. We've found many applications wasting lots of processing time writing to a null Java console.
Although helpful in debugging, writing to the console usually involves a great deal of string manipulations, text formatting, and output. These are typically slow operations. Even when the console is not displayed, performance can be adversely affected.
Don't overuse synchronized methods. Synchronized methods take longer to execute than unsynchronized methods and limit the multitasking present in the JVM and operating system.
Some projects have realized performance improvements by writing synchronized and non-synchronized versions of the same method, and invoking the synchronized method only when needed.
Create an object and cache it when no longer needed, then reinitialize or reuse it when a new object is needed. This will save the cost of object creation/initialization and later garbage collection. This could offer significant performance improvement to your applications.
Example 2 below ran about 50 times faster than Example 1. The difference between the two examples is that the allocation of the GregorianCalendar object is pulled outside of the "for" loop in Example 2. (That is, we are reusing the GregorianCalendar object).
Example 1:
for (int _i = 0; _i < 10000; _i++) {
h = GregorianCalendar.getInstance().
get(Calendar.HOUR);
m = GregorianCalendar.getInstance().
get(Calendar.MINUTE);
s = GregorianCalendar.getInstance().
get(Calendar.SECOND);
}
Example 2:
GregorianCalendar g = new
GregorianCalendar();
for (int _i = 0; _i < 10000; _i++) {
h = g.get(Calendar.HOUR);
m = g.get(Calendar.MINUTE);
s = g.get(Calendar.SECOND);
}
Example 3 below is a technique for "caching" objects. Example 3 runs about 25 times faster than Example 1. It uses a Hashtable collection class to store previously allocated and initialized objects for later use. Object allocation is removed from the "for" loop and replaced with a hash table look-up .(Note: Java2 has made some significant improvements in the collection classes in terms of usability and convenience, making techniques such as Example 3 easier).
Example 3:
Hashtable dates = new Hashtable();
GregorianCalendar g = new
GregorianCalendar();
dates.put("wifeBday", new
GregorianCalendar( 1946, Calendar.
AUGUST, 1, 8, 52. 32));
dates.put("budBday", new
GregorianCalendar( 1970, Calendar.
JULY, 4, 23, 10, 15));
dates.put("sisBday", new
GregorianCalendar( 1973, Calendar.
MAY, 21, 21, 01, 00));
for (int _i = 0; _i < 10000; _i++) {
g = (GregorianCalendar)dates.
get("wifeBday");
h = g.get(Calendar.HOUR);
m = g.get(Calendar.MINUTE);
s = g.get(Calendar.SECOND);
}
An article that discusses object "caching" techniques is "Writing Advanced Applications" by C. Austin and M. Pawlan (see chapter 8). see Chapter 8.
In cases where the same objects are frequently created, used, and then discarded, a performance improvement can be realized. This reduces the amount of garbage collection needed and avoids the need to create the objects repeatedly.
In the following example, the second method will execute faster than the first one. Final methods can be handled better by the JVM, leading to improved performance. The final method call can be placed inline instead of making the explicit method call by the compiler. For small routines, the overhead of function calls can be avoided at the expense of a modest increase in storage.
void doThing() {
for (int i=0; i<100; ++i)
dosomething;
}
final void doThing() {
for (int i=0; i<100; ++i)
dosomething;
}
When data is invariant, declare it as static and final. Performance can be improved by using local variables.
In the following example, the first array will need to be created and initalized each time the object test is instantiated, but the second array will only be initialized once:
class test {
int myarray
[] = { 1,2,3,4,5,6,7,8,9,10,
2,3,4,5,6,7,8,9,10,11,,
3,4,5,6,7,8,9,10,11,12,
4,5,6,7,8,9,10,11,12,13,
5,6,7,8,9,10,11,12,13,14 };
static final int myarray2
[] = { 1,2,3,4,5,6,7,8,9,10,
2,3,4,5,6,7,8,9,10,11,
3,4,5,6,7,8,9,10,11,12,
4,5,6,7,8,9,10,11,12,13,
5,6,7,8,9,10,11,12,13,14 };
}
Reducing the number of times variables need to be initalized and giving better optimization information to the JVM, improves performance.
In the following example, int is 32-bit data type while long is 64-bit data type. 32-bit operations are executed faster than 64-bit on 32-bit hardware/software systems. Example 1 takes about half of the time of Example 2.
// Example 1:
int i;
long q;
{
int j = 0;
for ( i = 0; i<250000;i++)
{
j = j + 1;
}
}
// Example 2:
int i;
long q;
{
int j = 0;
for ( q = 0; q<250000;q++)
{
j = j + 1;
}
}
In the following example, performance can be improved by using local variables. The code in example 1 will execute faster than the code in Example 2.
// Example 1:
public void loop() {
int j = 0;
for ( int i = 0; i<250000;i++)
{
j = j + 1;
}
}
// Example 2:
int i;
public void loop() {
int j = 0;
for (i = 0; i<250000;i++)
{
j = j + 1;
}
}
Vectors are more flexible than arrays, but much slower. Avoiding vectors when arrays will suffice, improves application performance.
When repeatedly using non-local variables in a loop, creating a local copy of the variable can improve performance. However, this must be weighed against the additional memory required to create an additional copy.
It is faster to add and delete items from the end of a vector and will improve application performance.
Unlike C++, casting in Java is not done at compile time. Since there is a cost at run-time, avoid unnecessary recasting of variables.
If you need to keep adding characters to a String (concatenation), use a StringBuffer; StringBuffer is designed to efficiently handle such modifications.
Since strings are immutable, any change to a string will create at least one more string object. This degrades performance and unnecessarily creates objects that will eventually need to be garbage collected. StringBuffers, however, are modifiable and can be used to avoid creating temporary String objects.
Example 1:
String result = new String("");
String part1 = new String(" first part +");
for (int _i = 0; _i < 10000; _i++) {
result = result + part1;
}
Example 2:
StringBuffer result = new StringBuffer("");
StringBuffer part1 = new StringBuffer
("first part +");
for (int _i = 0; _i < 10000; _i++) {
result.append(part1);
}
Example 2 runs about 400 times faster than Example 1. For further discussion of this point you may want to look at the article "StringBuffer versus String - JavaWorld March 2000" by Reggie Hutcherson
On current S/390 systems, avoid using long divides creation and manipulation by using primitive types. If possible, recast algorithms to use multiication or shifting instead of division.
|
