inline efficiency, or lack thereof

Can anyone provide me with an example of an inline function that actually hinders or helps? I was just implimenting a function, which I deemed worthy of being inline but I was then thinking, "does this indeed actually help? In fact, when ever could it help?"

I'm just curious, if anyone has any examples, links and or data I'd much like to see it.

inlining always helps speed up the program, but it may also make the program larger. Whether it helps or not depends on what you want to do -- do you want the fastest running program or do you want the smallest program size. Normally one-statement functions should be inlined. There is no guarentee that the compiler will actually inline the function even if you use the inline keyword -- compilers only treat that keyword as a suggestion and it is free to do whatever it wishes.

There are 10 types of people in this world, those who cringed when reading the beginning of this sentence and those who salivated to how superior they are for understanding something as simple as binary.

Many modern compilers automatically inline functions if you use them a lot (especially if you optimise for speed). So inlining a function might not do anything because it's already inlined! Compilers are free to ignore the inline keyword, too, and I'm sure some do.

dwk

Seek and ye shall find. quaere et invenies.

"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell

Nothing false about it. When the program does not have to call a function then it makes the program a tad bit faster. So where is the folly in that statement? This is not the same as saying the inline keyword will always produce inline code -- that is false as I also mentioned in my post.

Many modern compilers automatically inline functions if you use them a lot (especially if you optimise for speed). So inlining a function might not do anything because it's already inlined! Compilers are free to ignore the inline keyword, too, and I'm sure some do.

Well, duua! we are talking about inlining verses not inlining. inlined functions will ALWAYS make the program run faster than functions that are NOT inlined. This has nothing at all to do with whether the compiler does or does not honor the inline keyword.

A cache miss to code which isn't yet in cache (or worse, not even in memory) is going to be a lot worse than some nice tight code which has a few function calls, but it small enough to remain cache-resident all through its run.

>> Many modern compilers automatically inline functions ... Compilers are free to ignore the inline keyword, too, and I'm sure some do.

That just makes me wonder this - why did they bother making the inline keyword if the compiler chooses whether or not it is to be used? (I'm only being slightly sarcastic) They probably to do with the number of extra-marital kids the time ... right, Mario? Or is that just for size_types if the number of times the function is called exceeds the former number, it's inlined, else it's not.

Is it faster at building the exe when the functions are inlined, or if they aren't?

Inlining puts an optimization choice in the coder hands. The optimization comes from the fact that at runtime it's possible to avoid the extra cost of a function call. The keyword exists because there are tradeoffs. The most common one is an increase in file size. As such, the decision is left to the programmer to optimize or not.

It's important to understand that the decision to inline or not is not of the compiler. We speak "the compiler refuses to inline", when in fact probably the more correct way would be "the compiler can't inline". Some functions simply cannot be inlined (imagine a complex recursive function), others would lead to massive changes in code that would not respect anymore the original source.

However, I would do it differently. If I developed a compiler I would code in decisions to inline or not according to my mood. I don't know... like if an extra-marital kid suddenly showed up at my door.

Originally Posted by brewbuck:Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

Nothing false about it. When the program does not have to call a function then it makes the program a tad bit faster. So where is the folly in that statement? This is not the same as saying the inline keyword will always produce inline code -- that is false as I also mentioned in my post.

It's not just false because you could totally flush out the cache (but that's a reason), it's false because function calls are not necessarily more expensive. You can take a function that makes 100 function calls to another and move for loops around so that now you're making 10000 function calls, only to have the version with more function calls run faster. You could do this directly in assembly language and see the result. Or you could get the opposite result.

People get all jyzed up about function calls, but ultimately, it amounts to pushing one or two pointers onto the stack, and accessing the argument list in the child function. All these are operations in the closest cache to the processor, so these are fast. With all the instruction reordering and crazy stuff that processors do these days, the time you spend pushing the stack might have been spent waiting for addition circuits to clear out anyway, and the way instructions are aligned to word boundaries will have interesting effects.

Of course, inlining is still a Good Thing.

There are 10 types of people in this world, those who cringed when reading the beginning of this sentence and those who salivated to how superior they are for understanding something as simple as binary.