1

For an assignment, we're supposed to write two methods for handling outputs. One for outputting strings, and one for integers.

Basically we have two methods calling another method:

void TheClass::displayString(string str){ cout << str; }
void TheClass::displayNumber(int n) { cout << n; }

Will inline speed things up by saving some overhead by not calling yet another function or will it create more in regards to namespaces and such for cout?

inline void TheClass::displayString(string str) { cout << str; }
inline void TheClass::displayNumber(int n) { cout << n; }
Eva
  • 4,397
  • 5
  • 43
  • 65
Softnux
  • 2,440
  • 4
  • 20
  • 21
  • 1
    Your computer can run circles around `std::cout << b` for almost any type of `b` (the exception being user-defined classes with (deliberately) complicated output mechanisms). You don't need to worry about this. – Chris Lutz Jul 01 '11 at 23:35
  • 8
    Adding to Chris' comment, many professionals don't worry about this level of performance anymore. It's more important that the code be well-structured and easy to understand. You could worry about it and find that in a thousand years of running the code, a total of one second is lost! The better approach is to worry performance where there are obvious benefits, and then profile the code and see where the REAL bottlenecks are! – Codie CodeMonkey Jul 01 '11 at 23:42
  • The `inline` keyword does not necessarily inline a function. And inlining functions can have the adverse effect, and slow things down. Inlining generates more code, which means lower locality, and new code pages have to get paged in at a higher frequency. Irrespective of that, passing `std::string`s by value is likely to cost a lot more than you could ever save by inlining the function call. Don't optimize, until your profiler told you what to optimize. And don't run a profiler, unless there is a conceivable performance issue. – IInspectable May 16 '16 at 16:18

7 Answers7

13

Namespaces don't have anything to do with it.

You probably won't see any benefit here for one simple reason: the function is so small that I'd expect the compiler to be inlining it anyway.

Remember, the keyword inline is a hint not a directive, and usually you can just let your toolchain decide when to inline. It's good at that.

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
2

I agree with Tomalak, inline is only a hint, and you hardly get any benefit of inlineing a function. Today's processors are so fast that one more function call does not matter at all.

I used inline functions in opengl programming. OpenGL programs are infinite loops. To make the loop run as fast as possible you have to program very efficiently, so it will remain responsive to the user and will produce image smoothly. I believed declaring some functions inline would make the program run faster and smoother.

After all, don't expect huge performance upgrade from this technique, only 1-2 % less run time in extreme cases probably.

1

The inline keyword has very little to do with inlining of generated code. The inline keyword indicates that the function is being declared inline (that is, defined at its declaration) and so could have duplicate definitions in multiple compilation units. It is needed when you want to define a function in a header, as this function definition could be included in multiple compilation units, and without the inline keyword this would be a violation of the One Definition Rule.

If you are concerned about performance then profile your code while it is running, rather than asking people who have no idea what your code is doing to guess where your bottlenecks are.

Community
  • 1
  • 1
Mankarse
  • 39,818
  • 11
  • 97
  • 141
  • This answer pretty much sums up this matter: http://stackoverflow.com/questions/1759300/c-when-should-i-write-the-keyword-inline-for-a-function-method/1759575#1759575 – Mankarse Jul 02 '11 at 08:35
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/1080/discussion-between-pgroke-and-mankarse) – Paul Groke Jul 02 '11 at 09:58
  • "that is, defined at its declaration" - function definitions are _always_ declarations, and you may have as many declarations as you like. Don't be confused with the ability to `inline`-define functions in multiple TUs (since they have no linkage). – Lightness Races in Orbit Jul 02 '11 at 12:37
1

With those two functions, you probably won't see any noteworthy difference whether the compiler inlines the functions or not.

The reason is, that the stream insertion (<<) is rather slow. Much slower than one simple (non-inlined) function call.

And, as others have already pointed out, you should really get accustomed to passing strings by reference-to-const (and any other objects that are not really really cheap to copy).

There are some situations where it's preferable to pass by value, even (or especially) if the copy is expensive (e.g. when implementing operator = with copy & swap). But those are rare, and as long as you can't decide what's appropriate on your own, you're far better off always passing by reference-to-const then always passing by value.

Paul Groke
  • 6,259
  • 2
  • 31
  • 32
0

If you aren't spending a lot of time producing output, then this won't matter anyway. If you have profiled your program and determined that you are in the unusual situation that your program is spending most of its time producing output, then you can start considering how to make this code faster. You probably won't make it faster by adding the inline keyword, since your compiler is probably already inlining the function anyway, and if it isn't it probably won't do it even if you ask it to (though it might).

An easy first step to actually make your code faster would be to make your string parameter be a const string& instead. That way you won't copy the string. A more complicated second step would be to use the C output API instead of the C++ streams. The C API has been much faster in my experience, and that is backed up here and here. However I don't recommend moving to the C API unless you are sure you actually really need the performance based on profiling.

Bjarke H. Roune
  • 3,667
  • 2
  • 22
  • 26
  • The ostream::write function is usually pretty fast too. From what I've seen, most of the slowness of iostreams stems from the frequent use of locales. Which can be avoided by not using the "fancy" stream insertion operator and calling ostream::write directly. – Paul Groke Jul 02 '11 at 07:32
0

One way to optimize to have const-reference:

void TheClass::displayString(cosnt string& str){ cout << str; }
Ajay
  • 18,086
  • 12
  • 59
  • 105
0

Softnux, why don't you simply create a benchmark? Create a for loop with one million repetitions and see how much time it takes for each of the options. Then perform the benchmark separately for Debug and Release builds. Modern compilers should figure out when inlining or loop unrolling are the better option.

Edit: try with a string stream. Outputting to a console is going to be the bottleneck here, not the function call itself.

JSawyer
  • 110
  • 3