micro optimizations - Java-Gaming.org

I'm sorry to pout cold water on your efforts, but for improving performance this is nearly all pointless (it's rather useful for other things, like certain one-off cases where the optimization wouldn''t be "safe" but you have some special knowledge, like perhaps knowing that the program always throws an exception at some point before hitting i=0, and can do something about it). This isn't an opinion, its fact, and it's all to do with compilers.

One of the major reasons for using a compiled language is so that the compiler will do precisely the kind of trick you suggest here for you, and you can carry on writing in high-level code. In the bad old days when compilers still sucked (performance wise) it was worth doing such low-level optimizations, trading on the fact that a really good human programmer was better at optimization than a typical compiler.

Nowadays, you will find in general that such optimizations have more of a negative effect (when you try them across all main platforms) than a positive one - this is because you are not only second-guessing the compiler, and assuming that it wouldn't have made the same optimization itself, but you are reducing the number of additional optimizations it could have been doing, but which are way too clever for you to ever understand (unless you are a first-rate maths PhD or above).

With java especially, its not even possible to make statements like "this is one less instruction". You can make that kind of statement with C family languages, where you have a much better knowledge of what's going to happen to your code before it gets executed (compiled straight to assembler, for instance). The fundamental way that a Java VM works is to compile java byte code into code optimized for the machine its running on. As someone suggested (I can't remember if this is correct, but it sounds pretty likely given the 486 arch), this "optimization" might work best on a 386/486 class processor. But it would work slower than the "unoptimized" version on e.g. any processor family that has instructions for doing for loops with increasing loop-variables. (the java VM for that machine would have auto-recompiled the byte code to use the native CPU instruction, but now it can't).

It's better in general (unless you have a poor compiler) not to try this kind of clever optimization. When you factor in the additional loss to the programmer of the code now being less clear (unless you are willing to put 3 lines of comments explaining the bizarre implementation in front of each and every for loop!), the weight of evidence is in favour of avoiding this.

Even things like the good idea to reduce the number of times the "length" of an array is referenced are actually a complete waste of time. Every compiler today uses "live variable analysis" and "reachability" (feel free to google for them - should be slides on them in any really good Computer Science undergrad course) to automatically remove every single unecessary calculation. Although sometimes (as part of other optimizations) it can actually be better performance to deliberately compute something twice (and thats the kind of complex decision that the compiler will make for you - if you only give it the chance!).

Finally, its worth remembering that something which is well-suited to java byte code is often slower on most real machines than something that isn't. Java byte code was deliberately designed to be a really rubbish processor architecture for one of two reasons (depending on who you talk to in Sun):

1. They wanted it to be extremely easy to create a "hardware Java chip" that could execute java byte code. MAJC (the java chip) was much cheaper and easier for them to design and manufacture using 15-yr old techniques in processor design.

2. Java 1.0 came out when machines were a heck of a lot slower than today (I still have somewhere a copy of a Java VM for DOS!). Making java byte code a shitty inefficient architecture made it very easy for lots of different manufacturers and developers to write the first VM for each of the different platforms. Sun were rather worried that they might not achieve the critical mass of Java VM's for enough platforms (and it took quite a few years to happen, even with the very easy to implement java 1.0 VM's).