Excessive Inlining

Discussion in 'C++' started by Fei Liu, Mar 30, 2007.

  1. Fei Liu

    Fei Liu Guest

    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
    Fei Liu, Mar 30, 2007
    #1
    1. Advertising

  2. Fei Liu

    Fei Liu Guest

    LuB wrote:
    > On Mar 30, 11:42 am, Fei Liu <> 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?
    Fei Liu, Mar 30, 2007
    #2
    1. Advertising

  3. Fei Liu

    LuB Guest

    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
    LuB, Mar 30, 2007
    #3
  4. Fei Liu

    LuB Guest

    On Mar 30, 11:42 am, Fei Liu <> 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
    LuB, Mar 30, 2007
    #4
  5. 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
    =?ISO-8859-15?Q?Juli=E1n?= Albo, Mar 30, 2007
    #5
  6. Fei Liu

    LuB Guest

    On Mar 30, 11:56 am, Fei Liu <> wrote:
    > LuB wrote:
    > > On Mar 30, 11:42 am, Fei Liu <> 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
    LuB, Mar 30, 2007
    #6
  7. Fei Liu

    LuB Guest

    On Mar 30, 1:35 pm, Julián Albo <> 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
    LuB, Mar 30, 2007
    #7
  8. Fei Liu

    LuB Guest

    On Mar 30, 1:35 pm, Julián Albo <> 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
    LuB, Mar 30, 2007
    #8
  9. Fei Liu

    Ian Collins Guest

    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, Mar 30, 2007
    #9
  10. Fei Liu

    Ian Collins Guest

    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.
    Ian Collins, Mar 30, 2007
    #10
  11. Fei Liu

    LuB Guest

    On Mar 30, 3:24 pm, Ian Collins <> wrote:
    > 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
    LuB, Mar 31, 2007
    #11
  12. Fei Liu

    James Kanze Guest

    On Mar 30, 7:36 pm, "LuB" <> wrote:
    > 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:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Mar 31, 2007
    #12
  13. * 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?
    Alf P. Steinbach, Mar 31, 2007
    #13
  14. Fei Liu

    Ian Collins Guest

    James Kanze wrote:
    > On Mar 30, 7:36 pm, "LuB" <> wrote:
    >
    >>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:


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

    --
    Ian Collins.
    Ian Collins, Mar 31, 2007
    #14
  15. Fei Liu

    JohnQ Guest

    "James Kanze" <> wrote in message
    news:...
    On Mar 30, 7:36 pm, "LuB" <> wrote:

    "> 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
    JohnQ, Mar 31, 2007
    #15
  16. Fei Liu

    Ian Collins Guest

    JohnQ wrote:
    > "James Kanze" <> wrote in message
    > news:...
    >
    > 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.

    --
    Ian Collins.
    Ian Collins, Apr 1, 2007
    #16
  17. Fei Liu

    JohnQ Guest

    "Ian Collins" <> wrote in message
    news:...
    > JohnQ wrote:
    >> "James Kanze" <> wrote in message
    >> news:...
    >>
    >> 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?


    Reduction of the number of source files.

    >
    >> I agree that in general, inlining functions is bad because it increases
    >> dependencies.

    >
    > 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
    JohnQ, Apr 1, 2007
    #17
  18. Fei Liu

    James Kanze Guest

    On Mar 31, 4:03 pm, "Alf P. Steinbach" <> wrote:
    > * 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?


    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.

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


    > No template programming, then...


    Not at the application level, no.

    --
    James Kanze (Gabi Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Apr 1, 2007
    #18
  19. Fei Liu

    James Kanze Guest

    On Mar 31, 10:52 pm, Ian Collins <> wrote:
    > James Kanze wrote:
    > > On Mar 30, 7:36 pm, "LuB" <> wrote:


    > >>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?


    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.

    > > 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!


    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.

    --
    James Kanze (Gabi Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Apr 1, 2007
    #19
  20. * James Kanze:
    > On Mar 31, 4:03 pm, "Alf P. Steinbach" <> wrote:
    >> * 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?

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


    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.


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

    >
    >> No template programming, then...

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

    --
    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?
    Alf P. Steinbach, Apr 1, 2007
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Matt Jensen

    ASP PerfMon Excessive Requests Queued

    Matt Jensen, Dec 14, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    2,356
    Chris Huddle
    Dec 14, 2005
  2. Don Bala

    Tomcat and excessive threads

    Don Bala, Jul 21, 2003, in forum: Java
    Replies:
    0
    Views:
    424
    Don Bala
    Jul 21, 2003
  3. Mat K.
    Replies:
    17
    Views:
    536
    EightNineThree
    Oct 17, 2003
  4. Replies:
    2
    Views:
    303
    Keith Thompson
    Feb 21, 2007
  5. Dennis Yurichev
    Replies:
    0
    Views:
    332
    Dennis Yurichev
    Jan 14, 2007
Loading...

Share This Page