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 |

Our valued sponsors who help make this site possible
New Relic: Try free w/ production profiling and get a free shirt! 

ManageEngine's Site24x7: End-to-End analysis on Java EE web transactions. Sign up for FREE! 

AppDynamics: Get complete browser to backend visibility. Monitor Now! 

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

Chart Java Jitter with jHiccup
Monitor and identify pauses in your Java apps. Download now

Why is my application so slow?
Learn 3 ways to detect Java Application Performance Trends

JProfiler
Get rid of your performance problems and memory leaks!


Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

See Your Message Here
You could have your tool advertised here, to be seen by thousands of potential customers

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:


New Relic
New Relic: Try free w/ production profiling and get a free shirt!

ManageEngine
ManageEngine's Site24x7: End-to-End analysis on Java EE web transactions. Sign up for FREE!

AppDynamics
AppDynamics: Get complete browser to backend visibility. Monitor Now!


Chart Java Jitter with jHiccup
Monitor and identify pauses in your Java apps. Download now

Why is my application so slow?
Learn 3 ways to detect Java Application Performance Trends

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


Last Updated: 2014-10-03
Copyright © 2000-2014 Fasterj.com. All Rights Reserved.
All trademarks and registered trademarks appearing on JavaPerformanceTuning.com are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. JavaPerformanceTuning.com is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
URL: http://www.JavaPerformanceTuning.com/news/qotm034.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us