the purpose of all this low level mumbo jumbo is not just to enhance my self image as an eccentric dork. I love the way david moon keeps saying "but I haven't measured it".

the execution of java code is separated from it's execution in the execution units of the cpu by several layers of indirection: javac, the jvm jit compiler, the operating system, the instruction set architecture, the microarchitecture, on-die and off-die cpu caches. each of these utilize their own non-trivial optimizations.

so, while you can reason about the activities of any of these, if you want to know how they affect you, you really have to measure what happens. if results from measurements are unexpected, then something you know about the world between your .java file and the lowest level of hardware might help explain it.

as we are after real world performance, our measurements should happen at the appropriate level. if we are waiting for a web service to fetch our account data in XML format for 2 seconds over the network, it doesn't really matter what our registers do. most likely any optimizations we will have to make in response to measured and profiled performance problems will be at the higher levels of our code. without measurements, otherworldly pursuits of speculative gains are likely to hurt actual performance.

making code clean, readable and simple is virtually every time the most worthwhile optimization.

ctrl-d ctrl-d ctrl-d