Slashdot Mirror

This is primarily available on *NIX, but KL also has a C/C++ component called PageFormatter which has very similar functionality to JClass PageLayout.

Once again, it's not free and I admit that I'm biased, but it's still a good tool, and it can't hurt to download an eval to see for yourself.

Check out KL Group's JClass PageLayout. Quoting from the product page, it will "Output directly to the Java AWT Printer, Acrobat PDF, HTML, PostScript Level 2, or PCL 5."

I admit that I'm biased, but it's still worth checking out the eval.

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 page, but I've included two of them below.

How do you plug Java Memory Leaks? 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 and a text on the KL site.

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 page, but I've included two of them below.

How do you plug Java Memory Leaks? 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 and a text on the KL site.

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 page, but I've included two of them below.

How do you plug Java Memory Leaks? 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 and a text on the KL site.

With those in mind, there are a number of things you can do to improve Java performance.

• Minimize object creation at all costs. This means, don't use the "+" operator for Strings at all in production code, if possible. Remember that Strings are immutable and that every constant string in your code is another String object. It is far (hundreds of times) cheaper to use StringBuffer.append() instead. (If you don't believe me, use javap -c and check the bytecodes!)
• Do refactor your code. Smaller methods are not only easier to read, maintain, and reuse, but they are also more hospitable to profiling.
• You are using a profiler, right? I've used JProbe in industry, and it's output is a lot more useful than that of java -prof but it's pretty expensive to buy if you're on your own. A profiler is a must, though, because it lets you know what to optimize.
• Avoid unnecessary synchronization. This means (if you're using Java 2), prefer HashMap to Hashtable and ArrayList to Vector. (The newer collections classes are by default not synchronized.)
• Memoize values you use a lot. Actually, memoize any value you use more than once. javac by default won't do a lot of optimizations (like moving loop invariants outside of a loop), and some query methods are expensive. It is also a lot cheaper to access a local variable than an instance or static variable -- so any time you can cache the result of something you're using more than once, do it.
• Don't initialize unnecessarily. This is Java, not C++, and all variables are by default initialized (to 0 for integer and float types, false for booleans, and null for reference types); initializing integers to zero will just make object creation more costly.
• Be careful about using default constructors. If you're creating a lot of Hashtables that don't need to hold a lot of data, you'll be paying for the 1000-item default capacity if you don't specify a size.
• Pay for things once; pay for things all at once. If you need to look up mainly-static values from a db table (for referential integrity), read them all into a map of some kind, rather than doing a SELECT for every one. Also, prefer buffered I/O whenever sensible.
• Most of all, never resort to dirty tricks that make your code unreadable for the sake of a few more cycles. It's just not worth it.

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

There are several choices for solaris. dtbuilder, which is very simple and featureless but free and already in CDE/solaris. Sun's forte development environment, which can be try-n-buyed for 30 days or bought for anywhere between 300 (edu price) and 3500 USD. Both Kdevelop and GLADE work under solaris. Teleuse is actually not sold by telesoft, but by a company called aonix.

Just choose one of those options and you will be fine. If I had a choice myself I would use either Kdevelop or forte. Kdevelop because it uses qt so it is entirely c++ (which seems to be a requirement for you) as well as the possibility of portability since qt runs on windows. Forte, because Sun makes it so it will have Sun support as well as having a significant performance advantage on sparc.

If you decide on motif as your windowing toolkit and use forte and you have oodles of money in your pocket. Consider adding XRT. Very many high quality widgets which can improve the look of just about any gui.