|
|
|
|
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?
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.
Java performance tuning related news.
Java performance tuning related tools.
Back to newsletter 151 contents
