|
|
General coding issues
This section describes a variety of techniques to improve performance of WebSphere applications, particularly through the efficient use of the core Java functionality.
|
| Although strings are a simple and efficient data structure in many languages such as C/C++, there is overhead associated with the use of strings (java.lang.String) in Java. Java strings are immutable; once created their value cannot be changed. Hence operations such as string concatenation (+) involve the creation of new strings with the data copied from the original strings, creating more work for the garbage collector as well. When performing string manipulation operations, use of java.lang.StringBuffer as an alternative to java.lang.String can improve performance.
|
|
| Although the reflection facilities in Java can be extremely useful and allow for elegant implementations, reflection is an expensive operation that should not be used indiscriminately. This is another case of where a trade-off between performance and elegance of the solution needs to be made.
|
|
| Avoid creating excessively complicated class structures. There is a performance overhead in loading and instantiating these classes.
|
|
| Avoid excessive and repeated casting. Once an object has been cast, assign a variable of the correct type and reuse this reference.
|
|
| Use of "? : " for a conditional check instead of if-then provides better performance for most JVMs.
|
|
| When iterating n items, iterating from n-1 to 0 instead of 1 to n is quicker for most JVMs. See Example 18-3.
Example 18-3 Iterating through a loop n times
for (int=n-1;i>0;i--) {// Do something in a loop.....
}
|
|
| Avoid repeatedly calling the same method within a loop if the result is the same every time. Instead store the value in a variable prior to entering the loop and use this stored value for each loop iteration.
|
|
| Use System.arraycopy() to copy the contents of one array to another, rather than iterating across each array element and copying it individually.
|
|
| Where possible, declare methods with the final modifier if they will not be overridden. Final methods can be optimized by the compiler by method in-lining. The byte code of the method is included directly in the calling method. This avoids the overhead of performing a method call.
|
|
| When reading and writing small amounts of data, use of the Java Buffered I/O classes can significantly improve performance, by minimizing the number of actual I/O calls that need to be made.
|
|
| Avoid the overuse of exceptions. Throwing and catching exceptions can be expensive. Exceptions should be mainly used for (infrequent) error conditions, not as a normal mechanism for control flow by the application. Although throwing and catching exceptions should be minimized, checking for them with the use of try {} catch{} blocks is not particularly expensive so this can be used extensively if required. However, avoid catching an exception so that it can be simply rethrown and caught again later. Catch the exception at the level where it will be handled. Also beware of printing stack traces for exceptions, because they can be quite large.
|
|
| It is best to avoid spawning of new threads. Spawned threads do not have access to J2EE resources such as JNDI, security or transaction contexts. Rather than spawning a thread to act as a server to receive incoming messages, consider using message-driven beans (MDBs).
|
|
| In many applications, performance can be improved by performing some caching of data by the application. Note that if this is done, consideration must be given to periodically flushing the cache to avoid it growing continuously. Also be careful with making assumptions about requests for a client always being served by a particular appserver instance. Even if session affinity is used, in a failover situation, HTTP requests can be serviced by a different application server instance, which may not have the cached data. We recommend that the cache be implemented using a well-defined interface, and that data that is not in the cache be retrieved again, transparent to the rest of the application.
|
|
Prev | Home | Next
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both. IBM is a trademark of the IBM Corporation in the United States, other countries, or both. |