Optimizing Java? 29
cllajoie asks: "Every programing language has a list a mile long of optimization tips ranging from the mundane to the cryptic. I was wondering if anyone has compiled a list of these tips and tricks for Java. Some things are fairly easy, like adding final to methods so that they get inlined by the compiler, but what other deeper, darker secrets does Java have for making code faster and what are their implications on code size and memory usage? For example, if I had an accessor method is it better to use the this "pointer" in the return statement or not, or does it make any difference at all in performance? I mean lets face it, Java isn't blazingly fast to begin with so every little bit in the area helps."
Check Josh Bloch's book, and do not optimize early (Score:1)
Re:K&R on optimization; tips (Score:2)
Re:Check Josh Bloch's book, and do not optimize ea (Score:1)
Mea Culpa
Scott
Is it really necessary? (Score:2)
ditto... (Score:1)
No first hand experience in that sort of thing, I was kicked out of university, went in at the deep end, and now just write code that is quick dirty and meets (plus or minus the odd month, year, decade) deadlines.
Probably your best answer is to kick 7 shades out of your marketing & management, make them your bitches and you'll have the freedom to code good stuff.
Project Espresso (Score:1)
The functional spec. outlines the areas where Java sucks most and the program fixes them up automatically.
profiling (Score:2)
I discovered that operations on Strings are very very time-consuming.
I'd estimate a 2x speedup after optimizing three functions, thanks to -prof.
old page on the net on the subject (Score:1)
http://www.cs.cmu.edu/~jch/java/ [cmu.edu]
Leknor
http://Leknor.com [leknor.com]
Leknor
http://Leknor.com [leknor.com]
Re:Orphan Story (Score:1)
Louis Wu
"Where do you want to go ...
Re:Is it really necessary? (Score:1)
The choice of the VM can have a tremendous impact on the speed of code. For instance, Sun's HotSpot VM still sucks for client side code. For server-side code, HotSpot (and its garbage collector) can improve apparent performance considerably.
Here (Score:2)
Re: (Score:1)
OptimizeIt - A Java Memory Leak Finder (Score:2)
The Queue Principle
One little trick for embedded Java (Score:2)
Tim Beauchamp posted this to the TINI mailing list in the last couple of days.
Sorry about the formatting, I just cut and paste it from an email in my inbox
(Score:2)
Hmmm... (Score:1)
garbage collection (Score:1)
~wog
hashtable size (Score:2)
So I erred; mea culpa. I still maintain that it's an issue. There are a lot of applications where it is useful to create a lot of small hashtables as part of larger data structures (parsing certain kinds of languages in particular benefits from this), and if you have to allocate 101 pointers each time you make a mapping that will only use, say, 6, your performance will suffer because all that unnecessary allocation will make the GC hyperactive.
~wog
K&R on optimization; tips (Score:3)
1. Don't do it.
2. (for experts only) Don't do it yet.
With those in mind, there are a number of things you can do to improve Java performance.
You an find a lot of great performance suggestions in Peter Haggar's excellent Practical Java [amazon.com], a sort of Strunk and White or "Effective C++ for Java".
Good luck.
~wog
Re:hashtable size (Score:2)
So we both meant the same thing.
Re:K&R on optimization; tips (Score:1)
- With Jikes, you have a number of options, including obfuscation (which is just an algorithm to reduce code size -- smaller class & var names are used).
As I understand it, the obfuscation is only for protection of source code. Using the line number & local variable name tables, it is relatively easy to decompile code with a very high level of accuracy.Obfuscation has relatively little impact on program size, and no impact on runtime speed. With the use of the constant pool, there is only one copy of any class name, variable name, etc. I guess the code size could have an impact when you are downloading applets. But then you should be putting stuff in a jar anyway. At runtime the longer names in the code have no impact. Even in the earliest interpreting VM from Sun, the first time a method is called / field is accessed, the code modifies itself to replace the call/access instruction with a fast version. Once you take into account the 90/10 rule....
I could be wrong. :-)
It has been known to happen occasionally
- IDE's like JBuilder may actually have their use, if you just want to quickly make GUI's and concentrate on code internals. It deals with most of the Swing/AWT for you. Available on Linux. Automates some things for bad codewriters you might work with, to cut down on bugs.
I don't use IDEs - so the following is pretty uninformed. But the slowest and most convualuted piece of code that I have ever seen came from a Java IDE. (I think VisualAge was too blame.) It actually used- Class.forName("...").newInstance(...);
to create instances of other classes also produced by the IDE - it was as if the programmers didn't know the 'new' keyword existed. Urrgh.Confessions of a former java performance bitch (Score:3)
my best advice, the most important thing you can do is think small. You don't want to build big applications in java, you want to build small cute little applications that don't do a lot on their own. This is against the trends and norms of application development these days, today everybody wants to build these huge full featured integrated apps. Not a good idea in java. I worked on a 250,000 line java application that was designed to look and act like a normal windows application, only it never will perform like a normal windows application and java doesn't have a lot of things that normal windows apps do so you spend time building them (like wizards and that ilk.) Make java apps with java.
If you do that you will do two things, you keep the problem space small and you will keep it simple. This is critical. Some GUI things in java will just never be as fast as their native counterparts. That doesn't mean they can't perform acceptably and it doesn't mean java doesn't do other things very quickly. Paint()/WM_PAINT is just never going to be as fast in java as it is in C++. If you're building a visual component and blit-speed is the hangup then you have to reduce the number of blits or figure out a way to just deal with it. Your managment need to understand that there are classes of problems that java won't do as quickly and you have to be able to determine if your problem is one of those. Our app was so damn complex that it was difficult to pin point a single area of poor performance, let alone formulate improvments or calculate the benefit from spending the time on it. It was a classical build up failure, you could point optimizeit at it and the data told us that everything is slow, or rather everything is pretty fast but not lightening and so there wasn't a clear place to optimize, the little stuff adds up. Mix in a liberal dose of kingdom building and code protectionism and nobody on the team wanted to rework "their code" because they wanted to see what could be gained first but the analysis showed that everyone needed to do it. Worse, optimizing one piece of code didn't yield an exciting double digit performance increase, it was a tiny 6% increase and selling that to the other team members is a hard sell. "you mean I have to rewrite all my code and it's only going to be 5-6% faster? screw that!" If the app was simple this would have been a problem that is tractable.
Listeners leak. Creating dialogs with buttons and just letting the listeners go will cause memory leaks. Listeners register with AWT and need to be explicitly unregistered. Listeners point back to your buttons which often point to dialogs and even data. This is particularly problematic when you have a view/model type abstraction. We had literally hundreds of dialogs and buttons and essentially no GUI elements were ever garbage collected. This was an extremely non-trivial problem to fix and we didn't do it before I quit the company (IBM.) We had an object hierarchy in place where listeners were completely ignored during the design process. Many dialogs had multiple exit points. There just wasn't a clean way to fix the problem without making thousands of code changes. More alarming, certain members of the team refused to even acknowledge that there was a problem: "java doesn't have pointers...", "java has garbage collection.. it's impossible..." Once one person on the team was convinced and they started to grasp the gravity of it, they asked to get off the project and then they started trying to down play the performance significance because it was too big a problem to fix in our time frame. Here is how it kills you: GUI elements are built in to a tree in java (at least swing elements are.) That tree encompasses your entire visible/instantiated GUI, you do an update and that tree is traversed and each element is told to update itself. It's a very clean and simple model. The problem is when the GUI starts to contain hundreds and thousands of elements those updates start to take more and more time. Click, traverse tree, update update update...., see response. Add garbage collection and get close to filling the memory on the system and you've got a real performance problem, every time an event happens you will end up having to swap to update the tree and GCs will do it too. This is almost a non-problem if you keep it small, you may leak like a maniac but you have to leak megabytes and megabytes for it to really matter. We did so I know this. By the time you notice it, your app is way to big and unwieldly for this to be easy to fix.
Be smart with threads, reflection, and all the other goodies. Some of the language features java gives you are a dream to use, they also extract a price. Creating dialogs (or rather "notebooks") with hundreds of elements via reflection can be a hazard. Creating objects is expensive, do it as seldom as possible, write a pooling system if you have to. Be smart about data flow, with a view/model GUI you're going to be communicating between the view and model a lot, that adds up. Threads are addictive, they can also make the analysis of performance very difficult to understand, there is also an innate cost to creating and destroying them (provided that your don't have so many f-ing leaks that you can actually destroy a thread...) I never found a way to measure the time it takes for the JVM to traverse the class tree hierarchy, I have to assume that doing it repeatedly with a larger tree will cause a noticable difference.
There should be something said about JNI but I'm not sure what. Don't use it unless you benefit from it. Don't expect it to be a silver bullet. I think that with the JVMs of last year and our project, we used JNI so we could use a legacy communication library, JNI caused more problems than good. No easy ways to measure it's performance.
Yes and No. (Score:2)
-
At a guess I'd say that what works for one langage will work for another, get some books on algorithms and programing in general.
Yes, this is true, general good programming practice, and intellegent use of algorithms is important.But there are optomizations specific to the Java language, that people have not yet mentioned, and that everyone should know.
-
The use of the keyword 'final' has been mentioned above. You can also get the same effect from 'private' functions. But do not damage your libraries long term usefulness in exchange for a short term speed kick.
-
One of the (old) articles linked off another post suggests that having your java code call native code will be faster. This was true three years ago, when we had interpteting VMs. In Java 1.3, Sun has replaced a load of native math stuff in the standard libraries with java code. Doing this has increased speed of these functions by a factor of three or four. In most VMs, calling native code is very slow, and JITs are very fast.
-
Strings are immutable. The fact that the java language overloads the + and += operators can blind people new to the language about the importance of this. This is actually implemented using the class StringBuffer - e.g.
-
If you are writing applets, use
.jar files. The reason: if your applet has to downloaded a set of multiple seperate .class files (and probably other resources, such as .gifs), you must open seperate http request for each one. This is a lot slower than doing it all in one go.
Hope this helps.- class ex1 {
Compiles to exactly the same code as:int the_int;
public String toString() {
return "The value is " + the_int;
}
}
- class ex2 {
Obviously, in this situation, the first version is probably better. (The code is clearer). But you should never use the + operator to add Strings if you are doing multiple, seperate, adds. E.g.int the_int;
public String toString() {
return ((new StringBuffer("The value is ")).append(the_int)).toString();
}
}
- class ex3 {
Lots of nasty, wasteful Object creation.int the_int;
public String silly() {
String a = "A";
String b = "B";
String c = "C";
String ab = a+b;
return ab+c;
}
}
Oh, to address cllajoie's question about using the 'this' pointer: this produces exactly the same code.
-
Probably your best answer is to kick 7 shades out of your marketing & management, make them your bitches and you'll have the freedom to code good stuff.
I doubt that this would work...But nevertheless, I am certain that a lot more research should be done in this field.
Re:Confessions of a former java performance bitch (Score:2)
You know, if there was ever a place I thought that Java needed a "delete" keyword and destructors, this is it. Just think how much easier if you could "delete" a dialog when you were finished with it, and the dtor for the dialog could take care of removing all those listeners? This is one of the few times I wish I was still doing C++ instead of Java.
--
A "freaking free-loading Canadian" stealing jobs from good honest hard working Americans since 1997.
Re:garbage collection (Score:1)
My point is that you have little control over when the garbage collector interrupts your program and garbage collects. As a result, you will want to keep this to a minimum. To keep it at a minimum, don't do things that require garbage collection (spuriously allocating objects).
Optimizing Java (Score:1)
Re:profiling (Score:2)
I tried the -prof flag on my linux computer and I immediatly got a core dump. I tried it on my windows computer and it immediatly performed and illegal operation and had to be shut down. I am of course running recent versions of java from Sun. Methinks there are a few bugs and this is no longer supported or not yet supported.
Re:K&R on optimization; tips (Score:2)
One thing I would like to emphasize. Try to keep memory allocation to a minimum. Besides the obvious performance hit for allocating the memory and initializing the variables, you also run into issues with garbage collection. You really don't have too much control over garbage collection, either. I've seen one Java program in particular that would take seemingly random 30-second+ pauses on the MS JVM included with IE. It turned out that the only problem was that the garbage collector was running during these pauses. Garbage collection schemes are left up to the implementation of the JVM. Since you have little control over them (you can tell them to garbage collect on demand, at least), it is best to avoid turning control over to them unless absolutely necessary. Doing simple object pooling can enhance the performance of a program tremendously. For all you library developers out there, that means *don't* create immutable classes. Immutable classes prevent the use of object pooling.
Re:K&R on optimization; tips -- memory (Score:1)
Inserting a disclaimer here: I currently work for KL Group, the makers of JProbe.
Anyway, KL has published some articles and delivered some lecture's about performance-tuning Java, particularly in the area of memory use.
They are fairly helpful. Some of the points made in these articles are the same as what woggo made above, others are also useful information. These can be found off the JProbe [klgroup.com] page, but I've included two of them below.
How do you plug Java Memory Leaks? [ddj.com] This was published in Dr. Dobbs Journal.
Our CTO, Ed Lycklama, gave a talk entitled "Designing for Performance on the Java Platform" at JavaOne this year. There's a graphical [klgroup.com] and a text [klgroup.com] on the KL site.