Java Optimization

[darelf]

While I see quotes like "Java's poor performance is largely mythical..." I can't help but notice that Swing apps are just plain slow compared to other combinations (python + Qt, C + GTK, etc)

I am faced with needing to write some code for work in Java.

It needs to have a clean GUI (so most likely Swing).

I don't want it to run like it's been giving blood while it had the flu.

Are there any tips for performance of the GUI itself.... (I don't need tips on JDBC or collection classes, unless specifically GUI related) that you genius-types can fill me in on?

EDIT: Also, I hate Java, but that's just a personal opinion... sometimes you just gotta do what you gotta do....

[Isengard]

What kind of GUI ?
Just a form or a page showing puctures ?
Web based or stand alone application ?
Using JFrame or is it an Applet ?
A little more info might be helpful.

And for the record .. I love Java!

[darelf]

Ah... it's a form app.
You query a database, populate the fields, all the user to interact and view it ( including a graph ), and export the information locally.

My problem ( or the user's for that matter ) is not that the db routine takes a moment to return with the info. That part of Java seems very streamlined and efficient with the AS/400 toolbox.

The difficulty is that every action in the GUI seems a bit sluggish. It's a JFrame with a list box, some text entries and a couple of buttons. Also, there is a label that displays the graph.

I would assume that once the label had loaded the image ( .png format ) that there wouldn't be any more performance hit.

Where exactly are the slowdowns in such a program, or does Java just need "more machine" to run on? It's currently on a P2/266 with 32megs of ram as the target end-user machine.

EDIT: I just noticed part of your post... would an applet run faster?

[Dru Lee Parsec]

OK, here's some optimization tricks.

1. Build your dialog boxes (or at least the dialog boxes that you use most often) ahead of time during the splash screen.

2. Instead of killing your dialog boxes when you close them just use setVisible(false). This keeps them in memory so the next time you want to view that dialog box just do setVisible(true).

3. Using a Singleton design pattern will help you with both of the above issues.



public class MyDialog extends JDialog {

private static MyDialog theOnlyOne = null;

// The constructor is private. Build your Dialog box's GUI
// here. Because it's private nothing outside this class can call it.
private MyDialog(){

}

public static MyDialog getInstance() {
if(theOnlyOne == null) {
theOnlyOne = new MyDialog();
}

return theOnlyOne;
}
}


By looking at this code you can see that instead of creating an instance of MyDialog you instead use the static method getInstance() The first time getInstance is called it will construct the dialog box. The 2nd and all subsequent times getInstance is called it will return the already constructed instance of MyDialog. This will allow you to simply use setVisible with true or false to turn the dialog box on or off.

Also never mix AWT components (Button, Checkbox, Frame) with Swing components (JButton, JCheckbox, JFrame) Always use Swing. They're "lighter weight" and the look better.

Another technique is to call the garbage collection explicitly. One of the great things about Java is that it does automatic garbage collection (gc) . The bad thing about that is that the gc runs whenever the JVM decides it needs more memory. If this happens while you're using your app then you get a "hiccup" of slowness.

So, if you're in a part of the code where you know that immediate reaction isn't important at that moment then you can call the garbage collection manually with System.gc();

For example, let's say your program just ran a big database query and returned all that data in a JTable. Let's say that you KNOW that when the user runs that process they always take at least a few seconds to look at the data they just retrieved. That may be a good time to run System.gc(); That way, you make the garbage collector run when it doesn't effect the user.

If you were writing a game then you could run System.gc(); when you load a new level. Essentially, just run it when you know that the user experience won't be effected.


P.S.
1. I love Java.
2. An applet would not run any faster. SInce it has to be rendered inside a browser and is therefore dependent on the browser code it may run slower.
3. A P2/266 with 32Megs is considered a slow machine by today's standards. However, if you can get your GUI to render quickly on this computer then it will be blazingly fast on a 1.2Mhz with 512M or RAM.
4. Be sure you're using at least JDK version 1.3 (1.4.1 is the most current). If you're using 1.2 then download the HotSpot performance engine update. It will speed up the JVM and it also gets rid of some memory leaks that existed in the JVM.

I hope this helps.

[Dru Lee Parsec]

Found these links which may also help:
http://www.javaperformancetuning.com/

http://www-2.cs.cmu.edu/~jch/java/resources.html

[Halide]

haha I love your sig Dru lee :P