Slashdot Mirror
Eye on Java performance Improvements
An anonymous reader writes "Performance. It's the one aspect of the Java platform that continually takes abuse. But the overwhelming success of the platform on other fronts makes performance issues worth serious investigation. In this article, Intrepid optimizers Jack Shirazi and Kirk Pepperdine, Director and CTO of JavaPerformanceTuning.com, look at compilation speed, exceptions, and heap size tuning."
Level: Introductory
Just a note -- don't bother reading if you've ever looked into Java tuning before.
I admit I only skimmed the article... but the tips I saw are all simple suggestions that have been around for years now.
Use Jikes for quick compilations? Jikes has been around since before the Java 1.2 days.
Only throw Exceptions in "exceptional" cases, because they will slow things down? Again, advice I've been hearing since the early days.
Nary a word about exploiting the new IO classes, or evaluating performance of XML vs. custom formats, etc. etc.
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
They talk about how expensive it is to create an exception, and caution against it. Beware undue aversion to exceptions! For example, java.io.File.getLastModified(), if called on a file that doesn't exist, will return 0. An exception really ought to be thrown, but who's going to change the API now?
People emphasize performance too much. Look how successful PHP has been despite its slowness. Deal with functionality first, and only worry about performance if and when it's a problem.
Knowing when to optimize is more important than knowing how to optimize
Urban performance legends
If only I could come up with a good sig
Why?
Because if performance is an issue, you find your bottleneck and replace the
bottleneck Python code with a C module.
Suddenly your Python "Script" runs 99% as fast as if you'd written it in
C in the first place.
That's why nobody ever dogs on Python for being slow: Python makes it simple
to get the performance you'd expect from C while only requiring a minimal
amount of actual C code to be written.
*sigh* back to work...
...with less attitude (sorry, somehow I'm picking up the popular slashdot i-know-more-than-god tone... gotta watch that).
...and you may have also heard that this is nonsense and a great way to *ensure* that your project will fail because it's unuseable.
The article in question does do a good job of explaining why Exception creation is expensive.
I'm still dead-set against reuse of Exception objects, though, for some pretty good reasons. I've seen the suggestion before, and it bothers me because as optimizations go, it's very short-sighted.
I'm sure you've heard the suggestion to "code for the human, not for the machine", because you code *will* need to be maintained, unless your project fails.
As usual, the best answer is somewhere in-between. Every programmer should have the human reader in mind while designing and coding, but they should *also* design for efficiency. It has to be an informed compromise.
Reusing Exceptions is one of those examples that I like to use of how *not* to optimize. It's a basic misuse of an integral part of the Java idiom. Everyone understands how Exceptions work, and how to use the stacktraces to find your error. It's dependable. The poor sucker who's on call when a customer calls because this application keeps crashing takes stacktraces for granted, and is going to be beating his head on his desk after 2 hours trying to figure out what is going on.
This is a big cost. Okay, sometimes a cost is worth it, in optimizations. If this is a core data-crunching library that absolutely must perform at peak efficiency, maybe this is worth the painful maintenance cost.
In this case, though, I can't think of any benefit to balance this cost, except that a programmer somewhere is pleased with herself for using an optimization she read in a book. If this data-crunching library is throwing Exceptions left and right in its normal processing, it's using Exceptions wrong.
I hadn't thought about using the pre-made Exception hack to escape recursion -- it seems like a quicker way to get out than unwinding the recursion, after all -- but thinking about that more, I wouldn't suggest it even then. NOTE: comments below are not performance-tested, so if you really want to use recursion in a performance-critical part of an application, you should run some tests first.
To begin with, recursion isn't a very efficient process in Java. Each time the method calls itself, all of the current local variables are stored, a new copy of the method is made (with new locals), and execution continues in the new copy.
When you unwind the recursion, each of those stack frames and associated variables will need to be removed from the stack/heap and cleaned up, whether you exit normally or via an Exception.
If you do exit via a reused Exception, you're misusing the functionality (as discussed above), and the benefits -- which will be slim, if any -- aren't worth it, because there are better options.
If you're writing performance-critical code, you should use iteration, all in one method, instead of recursion, because it will perform better than even recursion with an Exception escape (probably in this case the cost is some readability.. recursion can be much more elegant).
If it *isn't* performance-critical code, then you shouldn't be worried about unwinding the recursion. And I still don't like misusing basic Java concepts, but you could even throw a new Exception to escape w/o worrying about performance -- after all, 1 million new Exceptions in 10 seconds is still pretty darn fast when you're only talking about throwing one.
-----
Wow, I hope someone reads this... it was a lot of work to write out!
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.