RE: How inlined are inlined functions?

[Anjul Srivastava <anjul dot srivastava at sanchez dot com>]

Believe me, I am sold on C++ !! And I would use them even if they were
umpteen times slower. I agree with you about your points about how to go
about attacking "hot spots".

I guess I was just frustrated because our group has a queer policy of
"scavenging for efficiency", and pushing any kind of move to C++ is perhaps
the most uphill battle I have faced, especially considering that I am one of
the juniormost persons.

Anyway, sorry if I made a big deal about it. I appreciate the fact that
inlining is useful as it is, and that there are perhaps better areas to
focus on, even in gcc. I also appreciate your prompt responses and the work
that Mark is doing on improving the inlining.

Cheers,
Anjul.


-----Original Message-----
From: Joe Buck [mailto:jbuck@synopsys.COM]
Sent: Friday, December 03, 1999 2:13 PM
To: Anjul Srivastava
Cc: jimb@cygnus.com; egcs@sourceware.cygnus.com
Subject: RE: How inlined are inlined functions?


> 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.