Excessive Inlining

F

Fei Liu

LuB said:
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
 
F

Fei Liu

LuB said:
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?
 
L

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.CreateIterator();

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(int, 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
 
L

LuB

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
 
?

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

LuB said:
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.
 
L

LuB

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<T> impl_;
};

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

std::list<T> impl_;
};



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_.GetSize();
}
};


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

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

std::list<T> impl_;
};


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
 
L

LuB

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.

-Luther
 
L

LuB

What gives rise to that fear?


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
 
J

James Kanze

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

Alf P. Steinbach

* 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
 
I

Ian Collins

James said:
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!

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

JohnQ

"> 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
 
I

Ian Collins

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

************* (I hate it when OE refuses to quote correctly!) ***********
Then either get a better client, or do what the other poor unfortunate
OE users do 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.

What purpose would it serve?
I agree that in general, inlining functions is bad because it increases
dependencies.

Nonsense, C++ would be pretty neutered without inlining of trivial
methods. Just compare the performance of an application with inlining
off compared to the same code with it on.
 
J

JohnQ

Ian Collins said:
Then either get a better client, or do what the other poor unfortunate
OE users do to quote correctly.


What purpose would it serve?

Reduction of the number of source files.
Nonsense, C++ would be pretty neutered without inlining of trivial
methods.

I wasn't talking about trivial methods. I was talking, obviously, about
functions that required additional header files.

John
 
J

James Kanze

* James Kanze:
Does it?
Measurably.

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

In this case, it means something that any programmer with
experience has run into. At least, if he's worked on programs
of any reasonable size.
No template programming, then...

Not at the application level, no.
 
J

James Kanze

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?

I'm refering to the use of the "inline" keyword, of course.
You're right that some modern compilers will inline without it,
across compilation units, and according to the profiler data.
Odd, I've never seen that. As Alf said, it would make using templates
kind of hard!

It does.

As with any rule, it can be violated when there are overriding
reasons to do so. But these are rare in application code, and I
can't remember every having seen a template definition in
application code in production software.

In practice, this isn't that restricting. "Application"
generally means dealing with known types anyway, unless you need
dynamic dispatch. Templates tend to be restricted to lower
level, very stable libraries. Libraries that are considered so
fundamental that 1) upgrading to a more recent version is
considered a major undertaking, much like moving to a new
version of the compiler and 2) if you do it, you recompile
everything and run the entire regression test suite again,
before going further.
 
A

Alf P. Steinbach

* James Kanze:
In this case, it means something that any programmer with
experience has run into. At least, if he's worked on programs
of any reasonable size.

I think that must be specific to the environment(s) you're used to,
and/or a statistical correlation between not-abiding-by-rules and low
quality code (which would not be surprising). I've seen the latter
effect, but not any problem from inlining per se. However, the few
sizeable C++ systems I've worked on have had far more serious problems,
obscuring any possible effect from inlining.

When you write "significant compiler dependencies" I think you mean
public module dependencies, i.e. undesirable public coupling, dragging
in headers that aren't really needed for the module's interface.

One way to deal with that is to focus on the undesirable coupling
instead of a language feature that one thinks is causing it.

Not at the application level, no.

ITYM that any template programming is by definition not part of the
application level. Then, not surprisingly, the application level turns
out to be a template free zone, except for use of (by definition)
library templates.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top