• Beware of “Thread.run()” versus the real intend of “Thread.start()” – We may unknowingly code the thread as “run()”.  This will cause the thread to run sequentially instead of concurrently. Beware of this!  Use “Thread.start()” to allow the thread to run concurrently.
• Use “String.length ()  == 0” instead of “String.equals(“”)” – Both constructs do the same thing of comparing if any characters exists for the string. However, the first construct, “String.length() == 0” is more efficient than the latter one.
• Avoid calling “String.toCharArray()” – “toCharArray()” method is inefficient as the method reallocates the entire array stored in the string.  However, sometimes this is necessary.  Therefore, as a rule, avoid using “toCharArray()” method if possible.  If not possible, do use it with care.
• Place “try/catch/finally” block outside loop – Placing “try/catch/finally” blocks inside loops can slow down the execution of code. Do take note that moving the “try/catch/finally” block outside the loop can change program behaviour. An exception that has the “try/catch/finally” block outside the loop will terminate early.  On the other hand, the “try/catch/finally” block inside the loop may cause the program to continue iterating over the loop even after an exception has occurred.
• Use “StringBuffer.Append ()” instead of “+=” operators for concatenating strings – “Append()” has better improvement over “+=” operators and its recommended to use it instead of “+=” operators for concatenating strings.
• Do not use “StringBuffer” as constants – Dynamically resizable strings are unnecessary for constant strings (as they do not change).  Instead, use “String” for non-modifiable string constants.
• Do not open or close JDBC connections in loops – It is inefficient to open and close a connection in loop.  Instead, the connection should be opened before the loop and closed after the loop to avoid redundant calls make to the database.

• Handle the appropriate exceptions (checked); do not leave it to the unchecked exceptions – When an exception is thrown, the runtime system will exhaustively search all the methods on the call stack for the appropriate exception handler.  This is expensive and thus we want to minimize the search in the call stack in finding the appropriate exception handler to improve performance which can be achieved by throwing and catching the appropriate exceptions (checked exceptions).  Do not leave exception handling as an after-thought or code-as-you-go during development.
• Do not incorporate exception handling as control flow – As mentioned earlier, exceptions are expensive and should only be used for abnormality (planned and unplanned).  An if-then-else construct will perform better without the exception handling as there is no need to transfer control to locate the appropriate exception handling.   As such, review the codes and remove any throw statements from the coding that are used in an if-then-else construct.
• Avoid and remove the use of Reflection API in the codes – Reflection involves types that are dynamically resolved, which restricts optimization in certain JVMs.  Consequently, reflective operations have slower performance than non-reflective counterparts.  Therefore, unless there is a dire need for reflection to be used in the java program, it is best to leave it out if you need a high performance program.
• Let the system decide the garbage collection – If possible, remove any attempt to call system.gc(). system.gc() triggers a full collection , which includes tracing all live objects in the heap and sweeping and compacting the old generation. This can be a lot of work. In general, it is better to let the system decide when it needs to collect the heap, and whether or not to do a full collection.  Note: system.gc() merely signals (marks) the java program to do garbage collection, but it will not be an immediate garbage collection taking place.
• Reduce memory by avoiding the use of finalizers – An object is in the finalized state if it is still unreachable after running the finalize method, if any, has been run.  The finalized object is then awaiting deallocation and deallocation will not take place until the finalizer is run which is dependent on the VM.  The use of finalizer will extend the lifetime of the finalized object and it can be counter-intuitive when no deallocation takes place and when you intended to have the object being short-lived.   In order to avoid these short-lived objects being extended during the lifetime of the heap memory, it is best to consider the use of finalizers or free the resources explicitly.   (Source: Appendix A, The Truth About Garbage Collection and Java theory and practice: Garbage Collection and Performance)

How can we build a high performance web site through coding then?  Here are some basic tips you should note during development which should not be a big hassle for you to make changes anytime!

1. Remove any unused variables – The first thing and most simple thing you can do is to avoid creating unused variables.  Use static code analysers and look for variables that are initialized but not used.  Sometimes, in the midst of development, we leave out variables that aren’t used anymore and this can be removed to converse memory.

2. Free all resources – All created resources and variables should be released once they are not used.  This helps converse memory.  This will help optimize the memory usage and thus reduce the need for garbage collection cycle to take place.  Resources such as database connections and files are simple examples that you should close and release the resources.

3. Free all resources in the ‘finally’ block – Similar to [2], we want to free all resources.  However, this is catered to “unhappy” flow of the program code.  Free all resources that are used when exception arises if applicable.

4. Avoid calling methods in loops – This can be circumvented when the compiler optimizes the code.  However, if it doesn’t the loop condition will be calculated for each iteration during the loop

5. Avoid methods that may cause memory leaks – Methods such as split(java.lang.String), split(java.lang.String, int), substring(int), substring(int,int), nextElement(), nextToken(), nextToken(java.lang.String), group() and group(int) are candidates of memory leak.  There are quite a fair bit of search results on the methods that causes memory leaks.  You can refer to “Strings and Memory Leaks” from The Java Explorer for some information.  Avoid such methods whenever possible.  If not, do use it with care.

More to come on coding for high performance applications!  Share with us on your performance coding tips here too!