Excessive Inlining

[LuB]

How judicious ought one be when inlining small methods.

I once read that in general, most compiles will only inline 'one'
level.

IE: if all the following methods were declared/defined as inline in
their respective classes, can I expect the compiler to try and inline
them all?

obj.GetSize()
{
a.GetLen()
{
b.GetHead();
{
c.CreateIterato r();

I'm sorry if this is hard to understand visually. I'm just trying to
depict they the code would be logically 'copied' and embedded at
successive levels of the call stack.

<offtopic>
If I were more adept at GDB, or Visual Studio - I'd prefer to look at
the resulting ASSEMBLY to see for myself what it did. Maybe I can
execute the app in DEBUG mode and open the disassembly window - but
would that jump to the method declarations? I'm not as facile at
ASSEMBLY of the debugger as I wish. Suggestions or general rules?
</offtopic>

Contextually, I have written a wrapper class for a library that is
essentially composed of 'pass through' calls.

IE: I've created a C++ class interface over a set of C library calls.

struct GuiHelper
{
inline void SetWindowPos(in t, int, int, int)
{
::SetWindowPos( ...);
}
}

And I'm worried (per that article I seem to remember seeing) that if I
use any of these methods in my other functions - that I will have used
up my ONE inline call per function stack. In other word, if I use
these methods in other, inline calls, when will the compiler be apt to
eventually quit inlining things?

Quantitatively then, is judicious inlining important? or can I willy
nilly declare/define all very small tight methods as inline and be
confident that several small inlined methods calling each other will
likely, all be inlined.

--note: this also goes for Setters and Getters. I'm afraid of
supplying getX or getY methods for fear that anywhere they will be
used - they will use up the ONE level of inlining the compiler will
create - and consequently, might not be the best method of the stack
to have inlined.

Thanks in advance for any insight,

-Luther

[Fei Liu]

Re: Excessive Inlining

LuB wrote:

How judicious ought one be when inlining small methods.
>

Keep in mind that inline is just a hint to the compiler. The compiler
has the freedom to choose either inline or not inline the specified
subroutine.

If your profiling indicates that inlining a subroutine can significantly
improve application performance, consider adding 'inline' declaration.

Fei

[LuB]

Re: Excessive Inlining

On Mar 30, 11:42 am, Fei Liu <fei...@aepnetw orks.comwrote:

LuB wrote:

How judicious ought one be when inlining small methods.

>
Keep in mind that inline is just a hint to the compiler. The compiler
has the freedom to choose either inline or not inline the specified
subroutine.
>
If your profiling indicates that inlining a subroutine can significantly
improve application performance, consider adding 'inline' declaration.
>
Fei

Yes, I do know that it is just a hint.

Assume I am writing a library for someone else to use.

And, assume my classes in turn, wrap up some other library (MFC, WTL,
take your pick). I am essentially wrapping up some library ... writing
pass through calls ... and then handing the resulting class to someone
else. Maybe selling it someone else.

Will I be hurting someone else's code - by declaring and implementing
as "inline" all the simple, one line pass through operations in my
library.

-Luther

[Fei Liu]

Re: Excessive Inlining

LuB wrote:

On Mar 30, 11:42 am, Fei Liu <fei...@aepnetw orks.comwrote:

>LuB wrote:

>>How judicious ought one be when inlining small methods.

>Keep in mind that inline is just a hint to the compiler. The compiler
>has the freedom to choose either inline or not inline the specified
>subroutine.
>>
>If your profiling indicates that inlining a subroutine can significantly
>improve application performance, consider adding 'inline' declaration.
>>
>Fei

>
Yes, I do know that it is just a hint.
>
Assume I am writing a library for someone else to use.
>
And, assume my classes in turn, wrap up some other library (MFC, WTL,
take your pick). I am essentially wrapping up some library ... writing
pass through calls ... and then handing the resulting class to someone
else. Maybe selling it someone else.
>
Will I be hurting someone else's code - by declaring and implementing
as "inline" all the simple, one line pass through operations in my
library.
>
-Luther
>

How can it hurt someone else's code? Inlining only happens at link
time...What makes you think it might hurt someone else's code?

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

Re: Excessive Inlining

LuB wrote:

If I were more adept at GDB, or Visual Studio - I'd prefer to look at
the resulting ASSEMBLY to see for myself what it did. Maybe I can
execute the app in DEBUG mode and open the disassembly window - but
would that jump to the method declarations? I'm not as facile at
ASSEMBLY of the debugger as I wish. Suggestions or general rules?
</offtopic>

As a general rule, if you care about this things you must to look at the
code generated. Be an adept or not is optional.

--
Salu2

[LuB]

Re: Excessive Inlining

On Mar 30, 11:56 am, Fei Liu <fei...@aepnetw orks.comwrote:

LuB wrote:

On Mar 30, 11:42 am, Fei Liu <fei...@aepnetw orks.comwrote:

LuB wrote:
>How judicious ought one be when inlining small methods.
Keep in mind that inline is just a hint to the compiler. The compiler
has the freedom to choose either inline or not inline the specified
subroutine.

>

If your profiling indicates that inlining a subroutine can significantly
improve application performance, consider adding 'inline' declaration.

>

Fei

>

Yes, I do know that it is just a hint.

>

Assume I am writing a library for someone else to use.

>

And, assume my classes in turn, wrap up some other library (MFC, WTL,
take your pick). I am essentially wrapping up some library ... writing
pass through calls ... and then handing the resulting class to someone
else. Maybe selling it someone else.

>

Will I be hurting someone else's code - by declaring and implementing
as "inline" all the simple, one line pass through operations in my
library.

>

-Luther

>
How can it hurt someone else's code? Inlining only happens at link
time...What makes you think it might hurt someone else's code?

At the risk of being wordy, I think my perception is wrong .. and
maybe this is a question for a *compiler* newsgroup:

But, my fear was that ... in any given method, only one nested call
can be inlined. Given the following example, could the compiler inline
ALL of the methods? or is it somehow limited to just one. Notice how
they are nested/successive calls? Inline calling an inline ... etc. I
got the impression that the compiler was physically limited ... that
it wouldn't inline more than one of these methods in this particular
call graph.

class BigMethods
{
void methodA()
{
int len = myList.GetSize( );
}
};


class MyList
{
inline void GetSize() const
{
return impl_.size();
}
ListImpl<Timpl_ ;
};

template<typena me T>
class ListImpl
{
inline void size() const
{
return impl_.size();
}

std::list<Timpl _;
};



If that is the case, then I might be more apt (for pure performance
sake) to use direct access for some things and 'save' my single
possible inline call for something I can't easily replace with a
property?

class BigMethods
{
void methodA()
{
int len = myList.impl_.Ge tSize();
}
};


class MyList
{
inline void GetSize() const
{
return impl_.size();
}
ListImpl<Timpl_ ;
};

template<typena me T>
class ListImpl
{
inline void size() const
{
return impl_.size();
}

std::list<Timpl _;
};


Please ignore any technical problems with the above psuedocode - my
underlying question is in regards to inlining hints and compiler
limitations.

If I'm limited to one inline method per call graph - maybe I won't use
a low level wrapper - since those inline methods would use up my
single inline function per call.

Sorry if this explanation is confusing. HTH.

-Luther

[LuB]

Re: Excessive Inlining

On Mar 30, 1:35 pm, Julián Albo <JULIANA...@ter ra.eswrote:

LuB wrote:

If I were more adept at GDB, or Visual Studio - I'd prefer to look at
the resulting ASSEMBLY to see for myself what it did. Maybe I can
execute the app in DEBUG mode and open the disassembly window - but
would that jump to the method declarations? I'm not as facile at
ASSEMBLY of the debugger as I wish. Suggestions or general rules?
</offtopic>

>
As a general rule, if you care about this things you must to look at the
code generated. Be an adept or not is optional.
>
--
Salu2

What does it mean:

Be an adept or not is optional.

Thanks,

-Luther

[LuB]

Re: Excessive Inlining

On Mar 30, 1:35 pm, Julián Albo <JULIANA...@ter ra.eswrote:

LuB wrote:

If I were more adept at GDB, or Visual Studio - I'd prefer to look at
the resulting ASSEMBLY to see for myself what it did. Maybe I can
execute the app in DEBUG mode and open the disassembly window - but
would that jump to the method declarations? I'm not as facile at
ASSEMBLY of the debugger as I wish. Suggestions or general rules?
</offtopic>

>
As a general rule, if you care about this things you must to look at the
code generated. Be an adept or not is optional.

Yes. I agree with you. The proof is in the pudding.

>
--
Salu2

-Luther

[Ian Collins]

Re: Excessive Inlining

Fei Liu wrote:

>
How can it hurt someone else's code? Inlining only happens at link
time...What makes you think it might hurt someone else's code?

Says who?

--
Ian Collins.

[Ian Collins]

Re: Excessive Inlining

LuB wrote:

>
But, my fear was that ... in any given method, only one nested call
can be inlined.

What gives rise to that fear?

--
Ian Collins.

[LuB]

Re: Excessive Inlining

On Mar 30, 3:24 pm, Ian Collins <ian-n...@hotmail.co mwrote:

LuB wrote:
>

But, my fear was that ... in any given method, only one nested call
can be inlined.

>
What gives rise to that fear?
>
--
Ian Collins.

Sounds like it is ill founded. I seemed to remember reading it
somewhere. Maybe it was a limitation of one particular compiler.

Thanks for all the responses. I'll try to do some profiling.

-Luther

[James Kanze]

Re: Excessive Inlining

On Mar 30, 7:36 pm, "LuB" <lutherba...@ya hoo.comwrote:

How judicious ought one be when inlining small methods.

That's simple: you never inline anything until the profiler says
you must.

I once read that in general, most compiles will only inline 'one'
level.

Not the ones I use. G++ (the only one I've verified) handles 40
some levels if you inline a recursive function.

In general, any limits will be more because of the complexity of
the program to begin with. (Some older compilers wouldn't
inline anything with a switch statement, of course.)

On the other hand, most (but not all) compilers require the
definition of the function to be present in the compilation unit
in order to inline. Which, of course, introduces significant
compiler dependencies, and has a significant negative effect on
programmer productivity.

Most coding guidelines I've seen ban inline functions
completely, for this reason.

--
James Kanze (Gabi Software) email: james.kanze@gma il.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[Alf P. Steinbach]

Re: Excessive Inlining

* James Kanze:

On the other hand, most (but not all) compilers require the
definition of the function to be present in the compilation unit
in order to inline. Which, of course, introduces significant
compiler dependencies, and has a significant negative effect on
programmer productivity.

Does it?

General rule: "of course", "as we all know", and the like, most likely
mean "fishy statement ahead".

Most coding guidelines I've seen ban inline functions
completely, for this reason.

No template programming, then...

Cheers,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Ian Collins]

Re: Excessive Inlining

James Kanze wrote:

On Mar 30, 7:36 pm, "LuB" <lutherba...@ya hoo.comwrote:
>

>>How judicious ought one be when inlining small methods.

>
>
That's simple: you never inline anything until the profiler says
you must.
>

Considering 'inline' is a hint and modern compilers will inline where
they see fit, that's kind of a meaningless statement. Or are you
referring to changing the code, bringing functions into the current
compilation unit for example?

>
Most coding guidelines I've seen ban inline functions
completely, for this reason.
>

Odd, I've never seen that. As Alf said, it would make using templates
kind of hard!

--
James Kanze (Gabi Software) email: james.kanze@gma il.com

Your signature is malformed, the delimiter should be "-- ".

--
Ian Collins.

[JohnQ]

Re: Excessive Inlining


"James Kanze" <james.kanze@gm ail.comwrote in message
news:1175348422 .117474.327060@ p15g2000hsd.goo glegroups.com.. .
On Mar 30, 7:36 pm, "LuB" <lutherba...@ya hoo.comwrote:

"How judicious ought one be when inlining small methods.

That's simple: you never inline anything until the profiler says
you must.

I once read that in general, most compiles will only inline 'one'
level.

Not the ones I use. G++ (the only one I've verified) handles 40
some levels if you inline a recursive function.

In general, any limits will be more because of the complexity of
the program to begin with. (Some older compilers wouldn't
inline anything with a switch statement, of course.)

On the other hand, most (but not all) compilers require the
definition of the function to be present in the compilation unit
in order to inline. Which, of course, introduces significant
compiler dependencies, and has a significant negative effect on
programmer productivity.

Most coding guidelines I've seen ban inline functions
completely, for this reason."

************* (I hate it when OE refuses to quote correctly!) ***********

Which begs the question: why is there no 'outline' keyword? Combined with
code-folding editors, it would make it easier to organize some class header
that have just a few or one outline function(s) (one file instead of 2 to
manage). Most compilers do seem to have an "outline all inline functions"
switch though. A curious experiment would be "inline all outline functions"
too. I agree that in general, inlining functions is bad because it increases
dependencies. A lot of code starts out that way though during development
until it evolves to the point where the major functions are moved to a .cpp
file.

John