Okay, now that you know everything that’s wrong with Java, let’s talk about what we can do with it.
The architecture and algorithms of your program are much more important than any low-level optimizations you might perform. Bad architecture and algorithms can make any system seem slow. Premature optimization may be the root of all programming evil (says Knuth) but failure to consider performance right from the start can also doom a program to uselessness. Here are some good guidelines:
Tune at the highest level first.
Make the common case fast (Amdahl’s advice).
Use what you know about the runtime platform or usage patterns. This violates portability in some sense. In fact, it will hurt later if the platform details or usage pattern changes. For example, optimizations that help before using the Hotspot JIT may hurt with Hotspot.
Look at a supposedly quiet system to see if it’s wasting resources even when there’s no input.
The cost of creating an object goes up with the size of that object’s inheritance chain. Since each superclass must be present before the subclass can be created, there can be a huge amount of network traffic for applets or RMI programs using objects with long inheritance hierarchies. On the other hand, keeping a small chain often conflicts with pure OO design principles. I’d sacrifice OO principles rather than write a very slow program. You will incur OO overhead in Java no matter what. Even with the ...