RReeaallyy long function -- inlining?

[Tomás]

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

 

[Noah Roberts]

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.

 

[Jakob Bieling]

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

 

[Tomás]

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

 

[Thomas Tutone]

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

 

[Howard]

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

 

[Tomás]

Howard posted:

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

 

[Phlip]

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]

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.

 

[Howard]

Howard posted:


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

 

[Phlip]

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!

 

[Fei Liu]

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.

 

[Gavin Deane]

Howard posted:


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