A review of some old best practices
OverviewBest 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 practicesThis article was written in 1997. Thirteen Great Ways to Increase Java Performance Is it still reliant today?
Use buffered I/OThis 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 problemsDate 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.HashtableLike 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 encodingThis 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.
Post a Comment