I'm not an expert on Java performance. What do you guys think about articles like http://www.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-jw22JavaUrbanLegends
which basically state that trying to avoid allocations is not worth the work in new JVMs?
Ooh, you shouldn't have gotten me started on that one: that article is complete and utter...umm, in the spirit of keeping this forum relatively clean and civil, let's say garbage.
Basically, although some of the theory
behind that article is valid, the specific advice entirely misleading, often cited, and was written based on way
too much wishful thinking about the current state of JVMs - the author should really know better than to give authoritative performance advice based on early beta builds with highly experimental features that might be pulled! If you use a normal JVM and do some tests today, you can see for yourself that his advice is flat out wrong, and garbage (or allocation - it's not clear what
exactly is to blame) most definitely does still matter - pure vector math performed with temporary objects allocated each time runs 2-4 times slower than the equivalent math performed with only floating point ops, and while I don't remember the exact numbers, there's a fair improvement when you reuse a private static temp object instead of creating new ones. That's not to say that today's JVMs aren't extremely good, they are, but they're not perfect and if we care about performance we need to take that into account.
Don't take my word for it, though, it's easy to write some tests yourself and check.
That article explicitly says "JVMs can use a technique called escape analysis, by which they can tell that certain objects remain confined to a single thread for their entire lifetime, and that lifetime is bounded by the lifetime of a given stack frame." Which would have been really nice
, if it was true about any JVM that was released and on people's computers.
Unfortunately Sun decided it was too tough to get right, and stripped it altogether from the early Java 6 VMs; scalar replacement has only recently started showing up in 6u14 betas (it's still
not in a release VM), and the ruling from on high is now that stack allocation is not worth the effort (which my cynical side reads as "It's hard and we won't put enough manpower behind the JVM to do it."). And we're now four years
after that article was written, advising people not to worry about it because it's "fixed" already!
Furthermore, it's now looking clearer and clearer that these optimizations will never
make it into the client JVM, and since the main engineer on the tiered VM sadly passed away, that project is probably never going to happen, either, so long story short - don't hold your breath on any of this ever helping game performance unless you're willing and able to bundle an entire beta server JVM with your game. At least until control of Java is snatched away from Sun, that is...(given that Sun is up for acquisition by IBM, that's looking more and more possible now).
So yeah...that article gives some very wrong performance advice. "Go ahead, make a mess" is exactly the last thing you want to do if you have performance issues. I really wish people from Sun would say something other than "There is
no performance issue" when asked to give performance tuning advice, it would make things a lot easier on us...