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."
At my work we have a program that is needed for information gathering. It was a custom job done by an outside agency. They chose Java as their language of choice. The program runs lots of processes and many threads. The average thread size is something like 52 MB. The total memory use of this program is something like 1.5 GB with about 500 MB of that resident in memory.
Can anyone explain why java uses so much memory or is it just bad programming by the contractor we used.
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...
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'm going to disagree that the IBM JDK is the fastest. In my experience (enterprise server apps), the BEA JVM, JRockit, is the fastest. We ran some tests that showed something like the IBM 1.4.1 VM was 2/3 faster than the Sun 1.4.2 VM, but BEA 1.4.1 was more than twice as fast as Sun's. We watched the execution speed over time, and JRockit took very few iterations to reach top speed. Sun and IBM both took many more iterations. What's particularly nice about BEA is the builtin monitoring.
Only throw Exceptions in "exceptional" cases, because they will slow things down? Again, advice I've been hearing since the early days.
One tip from Java Performance Tuning by Jack Shirazi is to create the Exception once, store it statically, and throw the object as many times as you need to.
Ugly? Sure. Hacky? Definitely.
But if you're after that extra bit of performance without leaving Java, need to use exceptions, and don't care about the stack trace, then it saves many cycles.
One thing that I've found with hig performance numerical routines is the cost of array lookup (with all of its runtime range checking) is something that can really slow a routine down. I've taken a routine that ran in 500ms and tuned it down to about 80ms (running under the Hotspot compiler). A comparable hand optimized assembler routine doing the same job took 20ms.
One example doesn't make a trend... but when you know what you're doing the performance is there for the taking.
Ian.
A physicist is an atom's way of thinking about atoms
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!"Its unfortunate that Sun's JVM is about the slowest one out there. Hotspot has never lived up to its potential. The poor performance of the reference implementation is one of the reasons Java has a reputation of being slow.