Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Excessive Inlining

Reply
Thread Tools

Excessive Inlining

 
 
Fei Liu
Guest
Posts: n/a
 
      03-30-2007
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
 
Reply With Quote
 
 
 
 
Fei Liu
Guest
Posts: n/a
 
      03-30-2007
LuB wrote:
> On Mar 30, 11:42 am, Fei Liu <(E-Mail Removed)> wrote:
>> 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?
 
Reply With Quote
 
 
 
 
LuB
Guest
Posts: n/a
 
      03-30-2007
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

 
Reply With Quote
 
LuB
Guest
Posts: n/a
 
      03-30-2007
On Mar 30, 11:42 am, Fei Liu <(E-Mail Removed)> wrote:
> 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

 
Reply With Quote
 
=?ISO-8859-15?Q?Juli=E1n?= Albo
Guest
Posts: n/a
 
      03-30-2007
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
 
Reply With Quote
 
LuB
Guest
Posts: n/a
 
      03-30-2007
On Mar 30, 11:56 am, Fei Liu <(E-Mail Removed)> wrote:
> LuB wrote:
> > On Mar 30, 11:42 am, Fei Liu <(E-Mail Removed)> wrote:
> >> 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<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

 
Reply With Quote
 
LuB
Guest
Posts: n/a
 
      03-30-2007
On Mar 30, 1:35 pm, Julián Albo <(E-Mail Removed)> wrote:
> 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

 
Reply With Quote
 
LuB
Guest
Posts: n/a
 
      03-30-2007
On Mar 30, 1:35 pm, Julián Albo <(E-Mail Removed)> wrote:
> 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


 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      03-30-2007
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.
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      03-30-2007
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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
inlining a text/plain mime attachment into email Matthew Lenz Perl 0 02-22-2005 05:39 PM
Java and inlining Aaron Fude Java 4 12-18-2004 02:39 AM
Tool or IDE for function inlining Alex Java 6 12-09-2004 04:00 PM
Function and variable inlining on Sun javac Ronald Fischer Java 3 07-20-2004 08:44 PM
local functions, namespaces, and inlining David Rubin C++ 8 01-15-2004 04:57 AM



Advertisments