An essential part of all Java development is performance optimization. A Java project is incomplete without extended discussions and arguments on optimization by the development team. The premise for all of these discussions is that Java is slow. Most refuse to look beyond this notion and believe that unless they get down and dirty, Java won't get the job done.
Have you had a look at any of those tools that claim to boost your computer's performance drastically? I often hunt on Download.com and similar sites to try out every such gizmo I can get my hands on. With due respect to the creators, however, it's always a futile exercise that tries my patience. Still, a few months down the line, I am again hunting for these same tools. It's just so difficult to come to terms with the idea that my computer is slow and I can't do much about it. The only solution that works well is to format my disk, get rid of unnecessary clutter, and install wisely. The superficial solutions don't work.
That is exactly what my experience has been with Java. If you are planning a performance optimization exercise after the end of coding and just before delivery, you might as well drop the idea. The performance gain would almost certainly not be worth the time and effort you would have to invest.
So should you just ignore performance and hope that your application performs within reasonable limits? Certainly not! Plan your application so that you do not unnecessarily introduce many levels of classes where each does not contribute much toward the performance of a definite task. It might be clich�d to say this, but overengineering is a big problem. I guess designers tend to get carried away trying to demonstrate their competence or their awareness of the latest tricks of the trade.
I have always felt that a designer who owns no responsibility toward coding or steps back once the initial design is done is unlikely to do a good designing job. Tell someone that he or she is responsible for coding the application based on the design, and in all probability, the design will move toward simplicity and not end up being a demo for design pattern usage.
I do not claim to be good at extreme programming, but I like what I have seen of it. The emphasis on keeping the system flexible and refactoring as required is a refreshing change from creating gigantic systems that supposedly provide for all eventualities.
My spell checker objects to the word refactoring, so I might as well define it here. The book Extreme Programming Explored explains the term as follows: "Refactoring is the process of improving the design of code, without affecting its external behavior. We refactor so that our code is kept as simple as possible, ready for any change that comes along."
I believe that a sleek design using low-tech solutions will always perform better than a bulky one that might be using cutting edge technologies. Often, projects end up getting complicated because of unnecessary usage of things like Enterprise JavaBeans (EJB). EJB might be a useful, but only in a select few cases. A vast majority of J2EE projects would be far better off sticking to JSP, servlets, Java classes, and maybe a framework like Struts.
A particularly intriguing part of the optimization exercise is the use of optimization tools. These tools are used so late in the process that doing something about any flaws revealed by their use is extremely difficult. Also, most of these tools are a little too complex for my taste. Many of the reporting screens are downright scary. I just want the tool to tell me the things that are obviously broken and how I should fix them. But the tools often tell you a million other things.
If you plan to use such a tool, use it while you are still developing and unit testing so that if something is found to be taking too much time or eating up too many resources, you can actually do something about it. In this regard, IDEs like Oracle9i JDeveloper, which have performance monitoring tools integrated into them, can be quite useful.
As Java Virtual Machines get smarter and faster, Java-based optimization is no longer as relevant as it was a few years back. So using any of the basic Java improvements won't be much help. If using the String class instead of the StringBuffer class makes your code more readable and understandable, I would go with String. A significant difference in the performance of these two classes appears only if that block of code is used thousands of times. Is that going to happen in your application?
Here are the optimization tricks I think will give you the most immediate returns:
- Minimize database access.
- Minimize Java IO, like reading and writing to files.
- Cache read-only data wherever easily possible.
- Unless you have to maintain backward compatibility, move to the latest JDK version. JDK 1.4 brought a lot of performance improvement over the earlier version, and these improvements are bound to continue into future versions.
- Test your application with JVMs other than the one provided by Sun.
- Make it a practice to log performance issues as critical bugs. That is the best way to get developers to seriously do something about it, as bugs generally get tracked and developer pride becomes a factor.
Overall, with the emergence of J2EE and distributed applications, basic Java language-based performance tuning is no longer as big a hurdle as it was a few years back. So do not let old notions and misconceptions fool you into not focusing on having a simple design, getting your logic right, and writing clean, maintainable code.
For more information on Java performance optimization, have a look at the book Java Performance Tuning by Jack Shirazi and the Web site Java Performance Tuning. Do share any optimization tricks that did wonders for your application by adding a comment to the article discussion.