views:

107

answers:

3

There are number of performance tips made obsolete by Java compiler and especially Profile-guided optimization. For example, these platform-provided optimizations can drastically (according to sources) reduces the cost of virtual function calls. VM is also capable of method inlining, loop unrolling etc.

What are other performance optimization techniques you came around still being applied but are actually made obsolete by optimization mechanisms found in more modern JVMs?

+2  A: 

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

Paul Tomblin
In this case, I believe the optimization still applies. The sample code you showed would construct 3 distinct StringBuilder instances, one for each concatenation; constructing only one would be (slightly) more efficient. Correct me if I am wrong.
RMorrisey
Oh, I thought it would do the equivalent of `String a = new StringBuilder("this").append(var1).append("is").append(var2).toString();`?
Paul Tomblin
this *unauthoriative* source http://www.rgagnon.com/javadetails/java-0129.html suggests Paul is right regards the single StringBuilder, but says the default capacity of the StringBuilder can be too short (strange, it would be trivial for a compiler that took the time to use a StringBuffer would not bother to count the capacity before use)
Will
Ok, I stand corrected!
RMorrisey
+2  A: 

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 mute. 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

Will
+2  A: 

The final modifier on methods and method parameters doesn't help with the performance at all.

Also, the Java HotSpot wiki gives a good overview of the optimizations used by HotSpot and how to efficiently use them in Java code.

Eugene Kuleshov
nice link, but it doesn't seem to dismiss `final`. It says that 'final' is a hint to inlining. I thought there were cases where final modifier will assure the compiler that its value cannot change in a loop even if that loop invokes other methods and beyond the current horizon.
Will
See: http://stackoverflow.com/questions/3961881/why-defining-class-as-final-improves-jvm-performance
andersoj
`final` on methods (or classes for that matter) provides no information to the JIT. However, `final` on a method parameter could very well provide useful optimizing hints (similar to a local variable declared as final). Ultimately, though, the reason to use final is to force immutability - this is a design-time characteristic to make code easier to maintain. Any optimization benefit would need to be a) only worried about if there was actually a performance problem, and b) tested exhaustively to ensure that it actually made a difference.
Kevin Day