That article was written 12 years ago. There's been some big changes in the Java world in those years.
1. Use buffered I/O.
= can't argue with that.
2. Try to avoid new.
= not as big a deal as it used to be
3. Native methods are really fast.
= This should probably be "native methods that are built into the JVM are really fast" because that's what he's testing. My personal rule of thumb is: "if there's a JVM method to do something, use it, because it's less code for me to maintain and it's probably
faster". As Kees Jan Koster states, worrying about small optimizations like this at the expense of solving the problem at hand is counterproductive.
4. String operations are fast.
= The author points out that "String operations can hide a lot of new operations." without an example. This article
explains how string concatenation can create lots of extra objects.
= If one needs the host address, what's the alternative?
= has long since been deprecated in favor of Calendar
7. Avoid java.lang.String.hashCode()
= If one looks at the code of java.lang.String, it calculates the hash code once and stores it, so this is no longer an issue.
8. Architecture matters.
= This will always be true.
9. I have mixed feelings about java.util.Hashtable
= Two things: HashMap is available and is not synchronized, and synchronization isn't the problem it used to be
10. String.getBytes() takes about ten times as long as String.getBytes(int srcBegin, int srcEnd, byte dst, int dstBegin)
= never looked at either of these methods. My opinion is that if one is working with bytes a lot, one probably should use C and not Java.
11. Synchronized method invocation is about six times longer than non-synchronized invocation.
= As I linked above, not true any more.
12. Be careful about using lots of debugging code.
= True, one should use either the Java java.util.logging package or Log4J
to mange debugging on-the-fly, and one should always be cognizant when building Strings, especially if they may not be used (see my link in #4)
13. Profiles of the Java Web Server show it spending about 1-2% of its time running the garbage collector under most uses. So we rarely worry about performance of the garbage collector. The one thing you want to be careful about is response time.
= I'd agree with that. Concentrate on what really matters (i.e. getting the task done, not micromanaging Objects).