Obsolete Java Optimization Tips

Question

There are number of performance tips made obsolete by Java compiler and especially Profile-guided optimization. For example, these platform-provided optimizations can drasti

Answer 1

When using x64 JVM with RAM less than 32GB:

64bit JVM use 30%-50% more memory in comparision to 32bit JVM because of bigger ordinary object pointers. You can heavily reduce this factor by using JDK6+.

From JDK6u6p to JDK6u22 it is optional and can be enabled by adding JVM argument:

-XX:+UseCompressedOops 

From JDK6u23 (JDK7 also) it is enabled by default. More info here.

Answer 2

1. "Premature optimization is the root of all evil"(Donald Knuth)
2. It is useful to optimize only the bottlenecks.
3. You should analyze the code in each situation. Maybe you can replace the TreeSet by a fast HashSet because you don't need the sorting feature or maybe you can use float instead of double( look at the Android SDK).
4. If no technique helps you can try to rewrite a piece of code and call it via JNI, so that native code is working.

Answer 3

People replacing String a = "this" + var1 + " is " + var2; with multiple calls to StringBuilder or StringBuffer. It actually already uses StringBuilder behind the scenes.

Answer 4

In 2001 I made apps for a J2ME phone. It was the size of a brick. And very nearly the computational power of a brick.

Making Java apps run acceptably on it required writing them in as procedural fashion as possible. Furthermore, the very large performance improvement was to catch the ArrayIndexOutOfBoundsException to exit for-loops over all items in a vector. Think about that!

Even on Android there are 'fast' loops through all items in an array and 'slow' ways of writing the same thing, as mentioned in the Google IO videos on dalvik VM internals.

However, in answer to your question, I would say that it is most unusual to have to micro-optimise this kind of thing these days, and I'd further expect that on a JIT VM (even the new Android 2.2 VM, which adds JIT) these optimisations are moot. In 2001 the phone ran KVM interpreter at 33MHz. Now it runs dalvik - a much faster VM than KVM - at 500MHz to 1500MHz, with a much faster ARM architecture (better processor even allowing for clock speed gains) with L1 e.t.c. and JIT arrives.

We are not yet in the realms where I'd be comfortable doing direct pixel manipulation in Java - either on-phone or on the desktop with an i7 - so there are still normal every-day code that Java isn't fast enough for. Here's an interesting blog that claims an expert has said that Java is 80% of C++ speed for some heavy CPU task; I am sceptical, I write image manipulation code and I see an order of magnitude between Java and native for loops over pixels. Maybe I'm missing some trick...? :D

Answer 5

It is necessary to define time/memory trade-offs before starting the performance optimization. This is how I do it for my memory/time critical application (repeating some answers above, to be complete):

1. Rule #1 Never do performance optimization on the earlier stage of development. Never do it if your don't need it really. If decided to do it, then:
2. use profiler to find bottlenecks, review the source code to find the reasons for bottlenecks;
3. choose appropriate data structure with the best fit into the defined time/memory trade-offs;
4. choose appropriate algorithms (e.g. iteration vs recursion, etc);
5. avoid using synchronized objects from java library, if you don't need it really;
6. avoid explicitly/implicitly new object creation;
7. override/re-implement data types/algorithms coming with the java if and only if you are sure they doesn't fit your requirements.
8. Use small, independent tests to test the performance of chosen algos/data structures.

Answer 6

1. Don't manually call the garbage collector, it hurts performance on modern JVM implementations.
2. Integer instead of Long will not save much space, but will limit the range of the numbers.
3. Avoid hand generated Enum classes and use the built in Enum instead. Java 1.5 introduced real Enums, use them.