Re: std::pow implementation

[dewar at gnat dot com (Robert Dewar)]

> Inlining is an optimization; in all but the most obvious and trivial
> cases (e.g., simple assignments), it should be performed by a programmer 
> *after* profiling, and not before. "Premature optimization is the root 
> of all evil", according to Hoare and Knuth; in code reviews, I tend to 
> grumble about people who insist on inlining and using cute tricks, when 
> they haven't done any analysis as to how their choices affect code 
> quality and performance.

I strongly disagree with this. Profiling is simply not an effective way of
identifying functions that benefit from inlining. Profiling is a very crude
tool that is helpful in eliminating hot spots but that's all.

The reason for not taking this view of inlining is that unless you get in the
mindset that inlining will be done routinely by the compiler (at your direction)
then you will tend to shy away from the use of trivial abstraction functions
because you will worry about efficiency.

The quote about premature optimization here is wrong I think. What Knuth
was talking about (go back and look at what he really said, not just the
sound bite) was distorting the code prematurely and unnecessarily in the
interests of optimization.

In fact, the liberal use of inline tends to *prevent* premature optimization
(of the kind I mentioned above, avoidance of abstraction), and certainly does
not distort the code.