RReeaallyy long function -- inlining?

Discussion in 'C++' started by Tomás, Mar 31, 2006.

  1. Tomás

    Tomás Guest

    The common persuasion is:

    Big function -- leave it outline.

    Small function -- make it inline.


    In code I'm writing at the moment, I have a fairly long function, so it
    wouldn't cross my mind to make it inline. However, the function is
    invoked only once, and its invokation is at the very beginning of the
    program's execution.

    Regardless of a function's size, would it not make sense to make it
    inline if it's only called once, so that it's code is "expanded in-
    place" rather that there being some sort of memory redirection?

    Should I stick to the formula of "Big=outline, Small=inline" and simply
    rely on the compiler to expand the code in-place if the function is only
    invoked once?

    -Tomás
    Tomás, Mar 31, 2006
    #1
    1. Advertising

  2. Tomás

    Noah Roberts Guest

    Tomás wrote:

    > Should I stick to the formula of "Big=outline, Small=inline" and simply
    > rely on the compiler to expand the code in-place if the function is only
    > invoked once?


    May as well. The compiler will do what it does regardless. It doesn't
    have to obey the inline keyword. The only thing you will surely
    accomplish is to fill a header up with a bunch of code...which will
    increase your comile times and source code dependencies surely.
    Noah Roberts, Mar 31, 2006
    #2
    1. Advertising

  3. Tomás <> wrote:
    > The common persuasion is:
    >
    > Big function -- leave it outline.
    >
    > Small function -- make it inline.
    >
    >
    > In code I'm writing at the moment, I have a fairly long function, so
    > it wouldn't cross my mind to make it inline. However, the function is
    > invoked only once, and its invokation is at the very beginning of the
    > program's execution.
    >
    > Regardless of a function's size, would it not make sense to make it
    > inline if it's only called once, so that it's code is "expanded in-
    > place" rather that there being some sort of memory redirection?
    >
    > Should I stick to the formula of "Big=outline, Small=inline" and
    > simply rely on the compiler to expand the code in-place if the
    > function is only invoked once?


    If it is only invoked once, why care whether it is inlined or not?
    You will never be able to see a difference in performance.

    hth
    --
    jb

    (reply address in rot13, unscramble first)
    Jakob Bieling, Mar 31, 2006
    #3
  4. Tomás

    Tomás Guest


    > If it is only invoked once, why care whether it is inlined or not?
    > You will never be able to see a difference in performance.


    If it's called "outline", then the program counter will be moved.

    If it's called "inline", the control will simply flow into the function.

    -Tomás
    Tomás, Mar 31, 2006
    #4
  5. Tomás wrote:

    > > If it is only invoked once, why care whether it is inlined or not?
    > > You will never be able to see a difference in performance.

    >
    > If it's called "outline", then the program counter will be moved.
    >
    > If it's called "inline", the control will simply flow into the function.


    I'm not clear on what your point is. The increased time it takes to
    execute a function call - that is, push the current value of the
    program counter to the stack, load the program counter with a new
    value, and, and at the end of that, popping the saved program counter
    back into the stack - rather than simply incrementing the program
    counter (if the function is inlined) is on the order of nanoseconds.
    To the programmer and the user, what possible benefit could there be
    from saving a few nanoseconds?

    The rule should be don't inline unless there is compelling reason to do
    so. There isn't one here.

    Best regards,

    Tom
    Thomas Tutone, Mar 31, 2006
    #5
  6. Tomás

    Howard Guest

    "Tomas" <> wrote in message
    news:M0eXf.7750$...
    >
    >> If it is only invoked once, why care whether it is inlined or not?
    >> You will never be able to see a difference in performance.

    >
    > If it's called "outline", then the program counter will be moved.
    >
    > If it's called "inline", the control will simply flow into the function.
    >
    > -Tomas


    Are you saying that there's a discernable difference in performance between
    making a function call and not making a function call, when it's done ONCE?
    What, it'll take a millisecond longer? Forget about it... program for
    readability, correctness, and maintainability. Only worry about performance
    if you're having a performance problem.

    -Howard
    Howard, Mar 31, 2006
    #6
  7. Tomás

    Tomás Guest

    Howard posted:

    >
    > "Tomas" <> wrote in message
    > news:M0eXf.7750$...
    >>
    >>> If it is only invoked once, why care whether it is inlined or
    >>> not?
    >>> You will never be able to see a difference in performance.

    >>
    >> If it's called "outline", then the program counter will be moved.
    >>
    >> If it's called "inline", the control will simply flow into the
    >> function.
    >>
    >> -Tomas

    >
    > Are you saying that there's a discernable difference in performance
    > between making a function call and not making a function call, when
    > it's done ONCE? What, it'll take a millisecond longer? Forget about
    > it... program for readability, correctness, and maintainability. Only
    > worry about performance if you're having a performance problem.
    >
    > -Howard


    Yes, but I shouldn't throw performance out the window just because my
    code works.

    Let's say that it runs a milisecond longer:

    Now imagine we're decoding gigabytes of data, and that my "progam" is run
    twenty thousand times.

    20000 x .001 = 20 seconds


    -Tomás
    Tomás, Mar 31, 2006
    #7
  8. Tomás

    Phlip Guest

    Tomás wrote:

    > The common persuasion is:
    >
    > Big function -- leave it outline.
    >
    > Small function -- make it inline.


    Inlined opcodes don't automatically make something faster.

    The best rule is to out-of-line (or inline) absolutely everything, and then
    only inline (or out-of-line) items that profiling reveals work better.

    > In code I'm writing at the moment, I have a fairly long function


    If you make it shorter, then the odds increase that the function and the
    functions it calls can all fit in the CPU cache. Making the function long,
    inlining it, and inlining the functions it calls all might overflow the
    cache, making things slower.

    (If you make it shorter, you will also please anyone who must work with this
    function. Long functions are worse than 'goto'.)

    --
    Phlip
    http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
    Phlip, Mar 31, 2006
    #8
  9. Tomás

    Phlip Guest

    Noah Roberts wrote:

    > It doesn't
    > have to obey the inline keyword.


    Including it doesn't have to obey the out-of-line situation. It could inline
    things you declared out-of-line.

    --
    Phlip
    http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
    Phlip, Mar 31, 2006
    #9
  10. Tomás

    Howard Guest

    "Tomas" <> wrote in message
    news:geeXf.7752$...
    > Howard posted:
    >
    >>
    >> "Tomas" <> wrote in message
    >> news:M0eXf.7750$...
    >>>
    >>>> If it is only invoked once, why care whether it is inlined or
    >>>> not?
    >>>> You will never be able to see a difference in performance.
    >>>
    >>> If it's called "outline", then the program counter will be moved.
    >>>
    >>> If it's called "inline", the control will simply flow into the
    >>> function.
    >>>
    >>> -Tomas

    >>
    >> Are you saying that there's a discernable difference in performance
    >> between making a function call and not making a function call, when
    >> it's done ONCE? What, it'll take a millisecond longer? Forget about
    >> it... program for readability, correctness, and maintainability. Only
    >> worry about performance if you're having a performance problem.
    >>
    >> -Howard

    >
    > Yes, but I shouldn't throw performance out the window just because my
    > code works.
    >


    But who said the performance of a single function call was a problem in the
    first place?

    > Let's say that it runs a milisecond longer:
    >
    > Now imagine we're decoding gigabytes of data, and that my "progam" is run
    > twenty thousand times.
    >
    > 20000 x .001 = 20 seconds
    >


    20 seconds when processing gigabytes of data is hardly noticeable! Not to
    mention that the overhead of simply running the program would FAR outweigh
    such a performance penalty. And as was pointed out elsewhere, the cost of
    the function call would be nowhere near a millisecond in any modern
    computer.

    You're welcome to worry about whatever you want to worry about, but if
    you're asking advice here, you're going to get exactly one answer: it's not
    worth your time to worry about, unless you have some reason to beleive it
    actually IS affecting performance.

    -Howard
    Howard, Mar 31, 2006
    #10
  11. Tomás

    Phlip Guest

    Howard wrote:

    >> Yes, but I shouldn't throw performance out the window just because my
    >> code works.


    > But who said the performance of a single function call was a problem in
    > the first place?


    I don't see a way to underemphasize the following point, so I will reiterate
    it again. This will take me longer than the time Tomas will save if he ran
    his program from now until when the sun goes off main sequence, but here
    goes...

    When you inline opcodes, the function that calls them gets longer. Suppose
    that function Bar() calls your function Foo() 3 times. The length of your
    function was formerly len(Bar)+len(Foo). Now it is len(Bar)+3*len(Foo).

    If Bar's opcodes now overflow the CPU cache, then Bar() will thrash while
    calling its various opcodes. Formerly Bar() and Foo() fit next to each
    other in the cache, and Bar() called Foo() by simply jumping from one part
    of the cache to another, and back.

    There's more to performance than rabid inlining (or writing unmaintainable
    functions). Premature optimization is the root of all evil, and this thread
    is giving us a clear view of the effect!

    --
    Phlip
    http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
    Phlip, Mar 31, 2006
    #11
  12. Tomás

    Fei Liu Guest

    "Tomás" <> wrote in message
    news:yfdXf.7745$...
    >
    > The common persuasion is:
    >
    > Big function -- leave it outline.
    >
    > Small function -- make it inline.
    >
    >
    > In code I'm writing at the moment, I have a fairly long function, so it
    > wouldn't cross my mind to make it inline. However, the function is
    > invoked only once, and its invokation is at the very beginning of the
    > program's execution.
    >
    > Regardless of a function's size, would it not make sense to make it
    > inline if it's only called once, so that it's code is "expanded in-
    > place" rather that there being some sort of memory redirection?
    >
    > Should I stick to the formula of "Big=outline, Small=inline" and simply
    > rely on the compiler to expand the code in-place if the function is only
    > invoked once?
    >
    > -Tomás


    It depends. If the inline function is going to be expanded inside a loop,
    the function should be small. This way the cpu iCache can hold all the
    instruction in a loop and be more efficient. If a function is not expanded
    inside of a loop or potentially iCache sensitive region, it does not matter
    if it's big or small.
    Fei Liu, Apr 3, 2006
    #12
  13. Tomás

    Gavin Deane Guest

    Tomás wrote:
    > Howard posted:
    >
    > >
    > > "Tomas" <> wrote in message
    > > news:M0eXf.7750$...
    > >>
    > >>> If it is only invoked once, why care whether it is inlined or
    > >>> not?
    > >>> You will never be able to see a difference in performance.
    > >>
    > >> If it's called "outline", then the program counter will be moved.
    > >>
    > >> If it's called "inline", the control will simply flow into the
    > >> function.
    > >>
    > >> -Tomas

    > >
    > > Are you saying that there's a discernable difference in performance
    > > between making a function call and not making a function call, when
    > > it's done ONCE? What, it'll take a millisecond longer? Forget about
    > > it... program for readability, correctness, and maintainability. Only
    > > worry about performance if you're having a performance problem.
    > >
    > > -Howard

    >
    > Yes, but I shouldn't throw performance out the window just because my
    > code works.


    A lot of people here simply don't agree with that statement for the
    following reason. In a collaborative and/or professional programming
    environment (which I expect a lot of people here are used to), you
    shouldn't throw performance "out of the window" because it should not
    even come "inside the window" until the code works. And the performance
    criterion then is never "as fast as it could possibly be", it is "as
    fast as necessary to meet the client's requirement".

    > Let's say that it runs a milisecond longer:
    >
    > Now imagine we're decoding gigabytes of data, and that my "progam" is run
    > twenty thousand times.
    >
    > 20000 x .001 = 20 seconds


    Again, that wouldn't concern many of the people here. Based on the
    answers you've got, and some experiments you can do yourself, hopefully
    you can find out whether inline makes your program faster. But don't
    imagine it's the sort of optimisation that a lot of people care about.

    Gavin Deane
    Gavin Deane, Apr 3, 2006
    #13
    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. George Marsaglia

    Assigning unsigned long to unsigned long long

    George Marsaglia, Jul 8, 2003, in forum: C Programming
    Replies:
    1
    Views:
    671
    Eric Sosman
    Jul 8, 2003
  2. Daniel Rudy

    unsigned long long int to long double

    Daniel Rudy, Sep 19, 2005, in forum: C Programming
    Replies:
    5
    Views:
    1,184
    Peter Shaggy Haywood
    Sep 20, 2005
  3. Mathieu Dutour

    long long and long

    Mathieu Dutour, Jul 17, 2007, in forum: C Programming
    Replies:
    4
    Views:
    471
    santosh
    Jul 24, 2007
  4. Bart C

    Use of Long and Long Long

    Bart C, Jan 9, 2008, in forum: C Programming
    Replies:
    27
    Views:
    794
    Peter Nilsson
    Jan 15, 2008
  5. veryhotsausage
    Replies:
    1
    Views:
    1,795
    veryhotsausage
    Jul 4, 2008
Loading...

Share This Page