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.
Quick summary: Our software is good, thrashing is bad, and exceptions are still screwy.
I've had this sig for three days.
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
Perl if you never have to look at it again. ... :)
If you want others to be able to read your code, well
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
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.
Python is you want to be able to read it later.
There is a great example in "Programming Python 2nd Ed." by O'reilly. You can make it a Threaded or Forked server with just the examples in the book.
...or C. If you want to hack something together, use Perl. If you want lots of reusable code/objects/classes/whatever use java. If you want whatever your working on to be stable, tight and fast then use C for a small project like this...
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.
This is covered in the article. You're talking utter nonsense.
* Try not to use synchronized.
Yeah right. This is also covered in the article. Hey, have you read the article?
* Try not to create objects.
Guess not since that was also covered.
Do you know how ridiculous that would be? An object oriented language where you don't create objects? Sure, you can make everything 'static', but what are you going to do about arrays, in Java they are objects? Nearly everything in Java involves objects. Get real!
You should almost never try to not create objects. You may want to, at most, minimise the rate of creation.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"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.
If performance is an issue, why would anyone *use* J2EE *or* .NET?
May we never see th
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.
I'm a Java newbie who has tried IBM's WebSphere and BEA's WebLogic. My box has 512M, but both of these IDEs use all 512k and take minutes to load a simple "hello world" app. "javaw.exe" seems to take all of the memory and CPU. I am doing something dumb or do I really need more than 512M?
Oh no, there are plenty more after that... :o)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I dunno...there can be enough hate between C and C++ that I don't think Java and C will ever walk hand in hand. Therefore, Java will always be slammed for its speed.
I really recommend this reading: The StringBuffer Myth
bully Sun to add -Xnotrace option to disable stack trace in exceptions and make them efficient? Its nonsense to change class design because some feature that could be fast happens to be slow.
Consider someone writting a low-level library that treats some condition (say, a math overflow) as an error and throws exception. Later someone else writes a program that generates a lot of overflows and handles them. Do you really want them to rewrite perfectly working code?