Source : Hints for Optimising Java3D

15 tips to go from snails-paced to faster-than-a-greased-weasel!

Sam Taylor

November 2001

You've laboured away all semester on your 3D masterpiece. It's packed full of interesting features, clever behaviours, gorgeous geometry and tasty bitmaps. Java3D shouldn't get any sweeter; this is what the Wedge was built for. But there's just one thing ... the performance. Your magnificent application crawls along at a snails pace. It's real-time alright, but only if you think in geological terms. The universe itself will end before your app! It chugs. It bites. It blows. It stinks.

So how do you crank up the speed? In this article we'll run through a number of general optimisation techniques for all Java programs as well as providing some hints about how to deal specifically with Java3D.

Before we start, lets get one common misconception out of the way. Many people think that Java is inherently slow. It isn't. There are plenty of examples of Java running just as fast as the equivalent C++. And it's not just on contrived benchmarks or specialised numerical code: full-blown Java applications can be as quick as native compiled code if you are careful to avoid some obvious bottlenecks. So tempting as it may be to blame the Java Virtual Machine (JVM), the problem is almost certainly elsewhere. The trick is to avoid excessive use of the more expensive features of Java. A little careful optimisation and your sedentary Java code will be buzzing on a caffeine high!

One other thing before we start:

"More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity." - W.A. Wulf

I'm not sure who Mr Wulf is, but that's some sound advice he's offering. Someone who I have heard of is Donald Knuth. Don isn't known for his work on 3D visualisation, but he's still got heaps of street cred so it's worth listening when he says:

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." - Donald Knuth

The root of all evil. Strong words, but the message from both these lads is that optimisation should come second - program correctness must always come first. Make your program work, then make it work faster.

That said, it's easy to go too far the other way, and treat optimisation as one of the final steps in debugging. Although you shouldn't optimise too early, performance is a Fundamental Requirement of any real time application. That's Requirment with a capital R and like all other requirements it must be considered carefully in the design, not left until the last minute. In fact most of the techniques described in this article relate as much to design as they do to implementation. Java doesn't give you the same opportunities as C++ when it comes to ultra fine code tweaking. Optimising Java code usually means working at a higher level to guarantee that your object structure and class hierarchies are efficient. The bottom line: design an efficient system, build it, debug it, then profile and optimise it.

Enough with the generalisations. In the words of Maverick and Goose in the 80's classic Top Gun, "I feel the need, the need for speed"...