Slashdot Mirror
Optimizing Java?
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."
Default size for Java Hashtable is 11 and grows by (size+1) every time it needs resizing. Surely you can afford to allocate 11 pointers == 44 bytes when only your virtual machine takes ~20 megs.
If speed is that much of an issue, use the GCJ compiler (or TowerJ for that matter) and turn it into a binary. Little "tricks" like that usually end up making the code hard to maintain and can cause subtle errors to creep in. Also, your choice of VM can have a lot to do with the performance of the code ...
James
I just discovered the -prof option. Just use java -prof [whatever], and you will be treated to a java.prof file that contains quite detailed information about CPU usage, down to the function call.
I discovered that operations on Strings are very very time-consuming.
I'd estimate a 2x speedup after optimizing three functions, thanks to -prof.
This is a slightly old, but good article: http://www.javaworld.com/javaworld/jw-04-1997/jw-0 4-optimize_p.html
Optimizeit is a powerful profiling solution for Java developers looking to rapidly track down and fix performance issues such as memory leaks and performance bottlenecks in any Java programs. Optimizeit is essential for the detection of performance issues in application server environments. Optimizeit provides instantly integration with most popular application servers, its overhead limiting features ensure scalability and new offline profiling coming soon in 4.0 allows testing of applications in production environments
The Queue Principle
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
Install Perl, be happy. :-)
Matt. Want XML + Apache + Stylesheets? Get AxKit.
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
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, a sort of Strunk and White or "Effective C++ for Java".
Good luck.
~wog
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.
This is my signature. There are many signatures like it but this one is mine..
-
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.