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
Larry
Here is a recent study about java and .net.
.NET Performance case study, the latest study (an MDA productivity study was released a few weeks ago) based on their Application Server Baseline Spec. Except for the web services test, the two platforms came out mostly equal in performance. "
The result ?
"The Middleware Company has released a J2EE and
I always get amused when open source people spout of about how slow Java supposedly is and how much they love perl/python/php in the other. Java is pretty much faster than all of those. Yet nobody ever dogs on python (say) for being slow. Why?
From a user's point of view, here's what's important WRT Java.
* Java still uses a lot more memory and cycles than C/Pascal/C++/etc. Generally, if there's a Java program and a C equivalent, you want to use the C equivalent.
* The IBM JDK is the fastest current way to run Java on Linux.
* Eclipse is the free Java IDE that everyone loves.
* No, the Freenet people still haven't made a C version.
May we never see th
I was summarizing quickly (yes, I know it's the creation that's costly) -- the point is that these are details about the language that any Java developer probably already knows or can intuit.
I just wanted to warn off experienced developers who were expecting the "serious investigation" that was promised in the posting.
By the way, I would NOT suggest reusing Exceptions. What you should strive to do is ensure that, in normal usage of your application, Exceptions will not be thrown (hence your program will be operating at peak speed). When there are errors, though, throw Exceptions then -- because it doesn't help anyone for your app to speedily come to a false result because the errors was eaten somewhere along the way.
I.e., don't throw Exceptions as part of parsing user input -- it's part of your application's job to check input and report faulty entries to the user. You're handling it. BUT you probably should throw an Exception if a file you are using disappears.
A slightly better example -- if you wrote a SETI-at-home style application that checked if data was within certain bounds, it would be bad to have a method that threw an Exception when data was outside those bounds... and just keep catching those Exceptions until you found the data you wanted.
Sounds stupid, but newbies do this kind of thing sometimes as a simple way to bail out when you finish processing early in the method body.
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
I think Perl. Use POE; see poe.perl.org. Fast well structured code. POE is gods gift to Perl programmers (or at least Rocco Caputo's Gift).
.
Otherwise use java.nio. Unfotunately, since it is a new api there is only one shitty application framwork built around it called SEDA. At first, I thought SEDA was cool, then I used it, found problems, tried to report problems, got no response, noticed there have been no updates in nearly a year. Fuckers.
If you like Python there is a feature rich, event loop style app framwork called TwistedPython. Haven't used it but it looks good. Check out www.twistedmatrix.com
-- I am not a fanatic, I am a true believer.
Frankly, I didn't. I knew that exceptions were expensive, but I didn't know why; and somewhat moronic summaries like yours (no offense, yours was about par for the course in fact) didn't help me understand why.
By the way, I would NOT suggest reusing Exceptions.
I would, where appropriate. I've just benchmarked it on jdk1.4.1 running Windows 2000, and I've found that exceptions run 20x faster if you do that (throwing an exception 1 million times took 10 seconds, reusing took 0.5 seconds on a 650 Mhz Intel- and frankly, a million is a heck of a lot of exceptions!)
What you should strive to do is ensure that, in normal usage of your application, Exceptions will not be thrown (hence your program will be operating at peak speed).
Most of the time speed isn't anything because the program is fast enough. It's only important to run fast where speed is insufficient.
Sounds stupid, but newbies do this kind of thing sometimes as a simple way to bail out when you finish processing early in the method body.
It doesn't sound necessarily stupid. Return or break statements are usually more appropriate though. In some situations (like recursion) an exception is quite possibly the best thing to do; and in that case reusing an exception should be done.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"I used to stress about Java performance. I'm not sure it was ever warranted. Certainly, things are plenty fast enough now.
Not only have the JVMs improved - e.g. hotspot - but the servers and PCs I'm using now are 3 times faster (2.4Ghz vs. 800Mhz a few years back).
What I think they need to concentrate on now, is getting the memory usage back down. 100MB to run an eclipse IDE is just too fat. And it's hard being a JSP Host when each Servlet engine chews up 60MB of memory on my host servers.
FWIW, the 1.5 release sounds like memory will get a good looking at. Let's hope so.
...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.