JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 034 contents

In the book "Java Performance Tuning" (O'Reilly), you suggested turning off all assertions for production code. Isn't this bad practice? Some error checking is required in production code.

I agree that deployed code should retain as much error checking as possible. But "Java Performance Tuning", whether we are talking about the book, the website, or the general subject, is not always about optimal software practices. Java performance tuning is usually needed in the situation where you have already applied best practices, and unfortunately performance is not adequate. In my book and on this website I show practices which optimize performance, whether or not such practices are also "best practice". This is of course, dangerous, as more than one person has noted. Java performance tuning is about making tradeoffs to speed things up. It is unfortunate that tradeoffs are needed, but best practices aren't quite enough to get adequate performance in all situations.

While some performance tuning techniques are also best practice techniques, most performance tuning techniques force you to choose between good software practice and better performance; some performance tuning techniques are really "last choice practice", the antithesis to best practice. It is unfortunate that this is the case. This is one of the reasons why you should really only tune where necessary, i.e. where a performance problem has been identified, not guessed at.

I once extracted those performance tuning recommendations which were also best practices for a couple of "best practice" O'Reilly books. The resulting volume of text was about a tenth of my book. A guess that only one in ten performance tuning techniques is compatible with best practice programming is probably a good guess. But that doesn't mean that 90% of your application will be compromised. You normally only need to apply tuning techniques in small selected portions of an application, so keep using those best practices and leave tuning to when it's necessary.

To get back to your original point about turning off assertions for production, if you identify that assertions are causing a performance bottleneck, then selectively turning them off is a valid performance tune. Chances are that you will only need to turn off some assertions, those in the bottlenecked section of the code. But if your application is liberally laced with assertions throughout the code, it may be the sheer volume of assertions causing a performance problem, in which case you may have to turn them all off by default, and selectively enable those that are really essential for the production system. This is a typical type of tradeoff you make when performance tuning.

The JavaPerformanceTuning.com team

Back to newsletter 034 contents