On inlining in C++

[Andrew Haley]

Robert Dewar writes:
 > > Perhaps there is, but the Principle of Least Surprise favours a
 > > fairly literal interpretation of "inline".
 > 
 > I don't agree, a huge blow up in size, resulting in slower
 > execution because of icache overload, can also qualify as a
 > surprise.

I do not believe that would be a surprise to anyone who thought about
it for a minute.

The Principle of Least Surprise suggests that inline functions will
often increase code size.  A little knowledge about multi-level memory
architecture suggests that this might reduce execution speed.

 > Indeed we find that customers are quite often surprised to find
 > that -O3 is slower than -O2 (as well as generating lots of code).

Well, that's different: we weren't talking about -O3, where the
compiler looks for functions to inline.  We're talking about functions
explicitly marked inline by the programmer.  A naive interpretation of
-O3 is "optimize more (i.e. better) than -O2".  But we know that -O3
doesn't strictly speaking mean that.

No, the burden of evidence is surely on those who want inline to do
something other than what a fairly literal interpretation of "inline"
(and the gcc docs) would suggest.

Andrew.