Re: Inlining functions using *CONTAINS* statement

From: Richard E Maine (nospam_at_see.signature)
Date: 10/26/04 

Date: Tue, 26 Oct 2004 08:14:22 -0700

arimail77@yahoo.com (Arindam Chakraborty) writes:

> I wish to inline a function in a loop, but I can't manually replace
> the function call with its source code since the function is a HIGH
> maintenance function and will be updated/modified frequently...

Let me echo a variant of comments made by others. How sure are you
that inlining will be of measurable help anyway? Even though the loop
is most of the run time of the program, that doesn't mean that inlining
will necessarily help. Generally, inlining helps most with small
functions. When the function gets very complicated, the time required
to execute the body of the function tends to dwarf the call overhead.
Your description of the function as HIGH maintenance makes it sound
like the function is probably large enough to make it doubtful whether
inlining would help.

But I realize that there are a lot of qualifiers like "generally" in
the above para. Exceptions certainly exist. One could have a function
that was both high maintenance and yet also small run-time, etc.
So I'll assume that you actually would benefit from inlining... but I
do encourage you, who know (much) more about the situation than I do,
to consider the question.

> [1]. Is there any way to inline a function (maybe using CPP
> directives, or include statements) without replacing the function call
> with its source code.

Both CPP and include are *PURELY* textual replacements. Really.
They are completely identical to writing out the same text and putting
it there. There are no subtleties of consequence here. The most
"subtle" point about include is that a statement that uses continuation
lines can't be split across an include boundary... and that isn't
exactly very subtle. CPP doesn't even have that issue, as it is completely
independent of the compiler.

*IF* pure textual replacement will work, then those methods would be fine.
I would caution, however, that pure textual replacement could cause
maintenance problems just because it has no special meaning. The compiler
won't have any notion of the included text as being a distinct function;
it will just be included text. I cannot emphhasize to much just how
*NON*-special the included text would be.

This means that if you include the body of the function right in place
of where the function caall was, you won't be able to have
declarations in it, just like you couldn't have declarations in source
text that you otherwise put in the middle of the executable code. Your
included text would share the same scope as the text around it. This
means that anyone writing code to be included is darn well going to
have to look at the whole subroutine while writing the include file.
You'd be hard-pressed to avoid having to also make changes to the main
file (to add declarations). Seems like this would negate much of the
whole point of separating it out in the first place.

If you are using include to just put the complete function (declarations
and all) effectively in the same source file as the calling procedure,
that's different. See below.

> [2]. Does it matter in optimization and inlining (by compiler) if a
> function is defined using the CONTAINS statement within the calling
> program?

Inlining is just too compiler-specific to make any generalizations that
are of much value. One could say lots of things about what *COULD*
happen, but what compilers actually do is a different matter. For
example, one could argue, as you allude above, that functions that
follow a CONTAINS ought to be good candidates for inlining... but that
doesn't mean that any particular compiler actually will do so.

Some compilers might be more likely to inline functions that are in
the same source file... and include or cpp could be used to have that
effect. But you can *NOT* just assume this will automatically help.
It is too compiler-specific. You really need to read the documentation
of your specific compiler to see what (if anything) it says about
inlining. 

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain