On 17/04/2012 03:00 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>>     "Note that inline functions can bring a heavy cost. If the function
>> is called 10 times, the inline code is copied into the calling functions
>> each of those 10 times. The tiny improvement in speed you might achieve
>> is more than swamped by the increase in the size of the executable
>> program.
>
>    He seems to think that the 'inline' keyword forces the compiler to inline.
> It doesn't. The compiler is completely free to not inline it, if it decides
> that it would be detrimental.

He even /says/ that a few paragraphs later. "Inline is a hint, which the 
compiler may ignore."

>    As for increasing the size of the executable, who cares? If the executable
> gets a few hundreds of bytes larger, big deal.

Yeah, that's the really puzzling bit. I mean, unless the function is 
huge [which is a bad idea anyway], or is called from a bazillion places, 
why would inlining it "bring its own performance costs"? I don't get that.

>    The 'inline' keyword has a secondary, but much more important role,
> though: It's an instruction for the compiler that says, basically, "if
> this function appears in more than one compilation unit, don't give me
> a linker error; instead merge them into one".

OK, /that/ sounds rather more significant.

>    Anyways, 'inline' should usually only be used for very short functions
> that are absolutely crucial for speed. Otherwise there's little benefit.

The book claims that if you write a function body inside a class 
definition, that makes the method inline. Is this true? I thought there 
was no difference either way...

>> Now, I'm used to programming languages where the decision to inline
>> something or not is down to the compiler. It's not something an
>> application programmer would ever have to worry about. And it seems that
>> the inline directive is only a "hint" in C++ anyway, so I have to
>> wonder, whether this particular directive is now obsolete.
>
>    Some newer compilers (such as the newest version of gcc) are able to
> inline functions between compilation units. However, this is a rare,
> quite advanced feature. (AFAIK only gcc implements this so far.)

OK. Presumably /within/ a single compilation unit it's already going to 
inline anything it thinks is worth it though. (?)

>    Traditionally, if you need a short function to be as fast as possible,
> you need to define it in the module's header file, and then it *must* be
> declared 'inline' (or else you'll get linker errors).

Right.

>> I love the dire warnings that you could use a number less than 15,
>> because otherwise the program might consume a vast amount of memory.
>> (For goodness' sake, how much RAM does 15 stack frames take up?!)
>
>    That would probably be 15^2. The author might have been using a 16-bit
> DOS compiler.

He does mention DOS several times, yes.

Even so, there might be 15^2 function calls, but only at most 15 of them 
will be /active/ simultaneously - which means only 15 stack frames at 
once. No?

>> In other words, yet again, "now you know how this works, you don't need
>> to actually use it".
>
>    Recursion is often handy to implement algorithms that are very recursive
> in nature, but one should be careful to not use too much stack space.

>    Usually recursion is also slower than an equivalent iterative solution
> (*especially* if the iterative solution works with O(1) extra memory.)

Well, yes. As I understand it, by default C++ doesn't reserve a whole 
lot of stack space, so you're likely to overflow it quite quickly. And 
as you say, being non-recursive means you skip all the overhead of 
jumping into and out of functions, which is faster. (It probably enables 
more compiler optimisations too, I wouldn't wonder...)

>> Still, it does answer something I've always wondered about: What *is*
>> the C calling convention?
>
>    It actually depends on the OS.
>
>    You don't need to worry about calling conventions unless you are
> implementing something really, *really* low-level. Machine-code level.
> (One example would be if you are writing a compiler.)

I'm a curious soul. I think to have some idea how things work, even if I 
don't know all of the details... ;-)

Post a reply to this message