Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers| Heap dump analysers|

Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks! 

Training online: Concurrency, Threading, GC, Advanced Java and more ... 

Question of the month: Assertions, On or Off? September 2003

Get rid of your performance problems and memory leaks!

Modern Garbage Collection Tuning
Shows tuning flow chart for GC 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

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 team

Back to newsletter 034 contents

Last Updated: 2023-08-28
Copyright © 2000-2023 All Rights Reserved.
All trademarks and registered trademarks appearing on are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
RSS Feed:
Trouble with this page? Please contact us