posted 9 years ago
No. Compilers can optimize code in many different ways. In most JVMs, in fact, the JVM has the option to convert the bytecode into native machine-language instructions. And can even customize the generated code based on how it's been executed (the ration of "then"s versus "elses" in an "if" statement, for example. Only the simplest of bytecode interpreters would give you any chance of deducing runtime efficiency from simply looking at the bytecode. On top of that, even if you look at actual machine code, modern-day CPUs do so much internal pipelining, look-ahead processing and other tricks that you can no longer simply add up nanoseconds per instruction the way we used to. The actual execution time is so dependent on the data of the moment that you can only get a rough guess. And that's before externalities such as interrupts.
When it comes to optimizing, you can generally gain far, far more efficiency by use of an appropriate algorithm than you can by fiddling around with low-level instructions. A classic example I like to mention is when I changed a simple bubble sort for a shell sort. Most people would have gone for a quick- or heapsort, since they're "more efficient", but the data in this case was almost completely in order to begin with, barring several important exceptions that took too long to bubble. But if you pass data that's mostly sorted to a heapsort or quicksort, that's their worst-case modes and they'll perform really slow.
It's worth looking at how bytecodes work, but I wouldn't make it an essential part of my daily programming.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
1
