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 ... 

News June 2013

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 151 contents

We would all like our code to have no flaws, no leaks, and run as fast as possible. If you know there's a leak in your code, you'll fix it. If there's a way to make it slightly faster, you tend to make the change to do so. It's one of the reasons why you're not as productive as you should be. Yes, you read that right, NOT as productive. Let me give a specific example: suppose your application has a memory leak, you monitor the heap and find it's leaking a gigabyte an hour. Obviously you need to fix it?

A note from this newsletter's sponsor

New Relic - Try New Relic today and get your free Data Nerd shirt!
Free SaaS APM tool to monitor, troubleshoot, and tune apps
running on Websphere, Weblogic, Tomcat, Jetty, JBoss, Solr, Resin

Well, hang on, there's a couple of critical facts missing. How long does your application run? If it runs for one minute (it's a quick batch task run daily, maybe), do you care about the leak? Isn't it much much cheaper and much more productive to just give it enough heap to run for the one minute? What about if it runs for about an hour? Now is it worth fixing the leak or is the very cheap option of just having the heap big enough to last the run the best option? Fixing the leak, even if it's an easy diagnosis and fix, will take hours at minimum including proper UAT testing and redeployment to production. Whereas bumping up the heap is minutes.

It's an ugly solution. No coder wants to think they'll push out a nasty leak into prod and just leave it there. So you'll likely go and fix it anyway, even though you've just worked out that you don't need to. That's a productivity hit. And what about the situation where you are leaking one 100-byte object an hour, and the application runs a week before bouncing. That's a 17KB leak over the week. Should you fix that? Should you even spend time diagnosing it? I suspect you wouldn't even notice a 17KB change in most applications that run for a week.

The point I'm making is, tuning changes need a cost-benefit analysis applied. If it's much cheaper to bounce the service daily and there's ample window for that bounce, rather than fix that slow leak, just bounce it. Productivity improved, targets achieved, no issues. Now on to all our usual links to Java performance tools, news, articles and, as ever, all the extracted tips from all of this month's referenced articles.

A note from this newsletter's sponsor

Free Java Performance Tool - From AppDynamics
Fight fires in production with less than 2% overhead.
Gain complete visibility into your java app. Free Download!


Java performance tuning related news.


Java performance tuning related tools.

A note from this newsletter's sponsor

ManageEngine: Application Performance Management for Java EE Apps.
Monitor App Servers: JBoss, WebSphere, WebLogic, JVMs and JMX Apps.
*** Monitor up to 25 App Servers, Databases & Servers at $795/Yr***.


Jack Shirazi

Back to newsletter 151 contents

Last Updated: 2023-09-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