How inlined are inlined functions?

[Joe Buck]

> One of my key points was that we could eliminate ugly macros, and use inline
> functions. This basically helped me persuade them that C++ could in fact
> help us on a practical basis (even if we couldn't go to OO rightaway).
> 
> Imagine my embarrassment when I find that inline functions execute SEVERAL
> times slower than macros.

Even with 2.7.2 it was that bad (several times slower) only in rare cases.
By the egcs-1.0 time frame the penalty for inline functions was already
decreased in many cases by the ADDRESSOF optimization.

And even with the current performance penalties, most large projects are best
off still using inline functions in preference to macros, because
maintainability and code quality is more important than raw speed except
for the most time-critical of inner loops.

Still, it needs improvement.

> I think we should rectify this with high priority.

Mark Mitchell is already doing it and it will be in the next major
release.

> I am certain our
> implementation is not what Stroustroup had in mind when he talked about
> inlined functions.

I doubt if he was too worried.  Some might not be aware that when Dennis
Ritchie was asked about the efficiency of function calls in the original
C compiler, he basically lied (and he later admitted to this!).  He knew
that while the first compiler he had sucked, it would get better, but
if the users refused to break up their code into functions, it would be
a disaster, so he assured them that they shouldn't worry about it, that
functions are efficient.

So if you write code that you expect to have a lifetime of more than a
week and a half, you should focus on maintainable design, not raw speed.
Later on, you can do profiling, and only do speed hacks for the "hot
spots" in your code.  Those who have to maintain your code after you
will thank you.