A review of some old best practices

Overview

Best practices tend to date and what was s good idea ten years ago, may not be considered a good idea today.

A review of some old best practices

This article was written in 1997. Thirteen Great Ways to Increase Java Performance Is it still reliant today?

Use buffered I/O

This still applies today. It catches those New to Java, however I believe it is widely used.

Try to avoid new.

This doesn't apply as much as it used to, however there is still use cases where you want to avoid creating new objects, esp when you may be calling code many times. Unfortunately creating new objects is a common occurrence in the JDK and when it comes to rewriting libraries which come with the JDK, it usually because the functionality create needless objects.

Native methods are really fast.

They are even faster than they used to be. For some native calls the JVM is smart enough to inline the native code. Some natives methods are replaced with a single machine code instruction.

String operations are fast.

They have improved, but can still be a serious lag on performance. A common hidden drag you can your application is building Strings for debug message you don't print. I have seen applications which use up to 30% of CPU creating message that are not printed.

A simple workaround is to check if debug messages will be displayed before creating the message.

avoid InetAddress.getHostAddress()

Its work avoiding not becasue of the String operations, but because it can make network requests. However if you need this functionality there is no substitute for it. I would hope this is not a common problem for applications.

java.util.Date has some performance problems

Date has any number of issues including being mutable and SimpleDateFormat not being thread safe. Joda Time is a better choice in many cases however I find the built in classes suit my needs.

Where I need performance, I use custom date/time conversion routines which assume GMT timezone and are much faster than the built in classes.

GregorianCalendar is amazing complex and inefficient. Only use it if you needs to rich functionality.

Avoid java.lang.String.hashCode()

The hashCode for was changed and the issue mentioned here no longer applies. Every byte is examined for the hashCode.

Architecture matters.

Architecture still matters, however profiling your application is often just as valuable as application become so complex its impossible to know exactly where your performances hits will be coming from. Without measurement you will be just guessing.

I have mixed feelings about java.util.Hashtable

Like Vector this is a legacy replaced by List and Map implementations in 1998. But this suggest still applies because people still uses these classes 13 years later. :P

Converting a String to bytes can be ten time longer if you use Character encoding

This still applies to a degree today. Converting a "Hello World!" to "US-ASCII" was 4x faster using a straight copy of the bytes rather than using a Character Set conversion.

Synchronized method invocation is about six times longer than non-synchronized invocation.

This is no longer as extreme. Even simple functions like StringBuffer.append(char) vs StringBuilder.append(char) show a the synchronized method takes 30% longer. A more complex function would have a smaller relative difference.

If you need thread safety, you have to have it. Otherwise, it worth considering a avoid it, but it may not make that much difference.

Be careful about using lots of debugging code.

I would be careful will all debug code and logging which you expect could be turned off.

Find the optimal heap size for your application

Current JVMs are fairly good at tuning the GC while the application is running. If you make any changes you need to test them as you may find you have changed little or made things worse. ;)