In many cases, you're better off simply trusting your tools. Already in 1975, Fred Brooks observed that some compilers produced output that handwritten code couldn't beat. That's even truer today, so don't waste time on unneeded hand-optimizations. In your race to improve the efficiency of your code, remember that developer efficiency is often just as important.
Programming myth No. 7: Good code is "simple" or "elegant"
Like most engineers, programmers like to talk about finding "elegant" or "simple" solutions to problems. The trouble is, this turns out to be a poor way to judge software code.
For one thing, what do these terms really mean? Is a simple solution the same as an elegant one? Is an elegant solution one that is computationally efficient, or is it one that uses the fewest lines of code?
Spend too long searching for either, and you risk ending up with that bane of good programming: the clever solution. It's so clever that the other members of the team have to sit and puzzle over it like a crossword before they understand how it works. Even then, they dare not touch it, ever, for fear it might fly apart.
In many cases, the solution is too clever even for its own good. In their 1974 book, "The Elements of Programming Style," Brian Kernighan and P.J. Plauger wrote, "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" For that matter, how will anyone else?
In a sense, concentrating on finding the most "elegant" solution to a programming problem is another kind of premature optimization. Solving the problem should be the primary goal.
So be wary of programmers who seem more interested in feathering their own caps than in writing code that's easy to read, maintain, and debug. Good code might not be that simple. Good code might not be that elegant. The best code works, works well, and is bug-free. Why ask for more?