1

I've witnessed posts in SO mentioning inlining has made their software run significantly faster [example].
It made me wonder, when should I make a function inlined for performance?

Also, would the same guidelines for C++ inlining apply?

Note:
I'm not asking when (obviously when needed), or why, I'm asking that if I happen to reach a bottleneck, when would inlining could be helpful?

Community
  • 1
  • 1
MasterMastic
  • 20,711
  • 12
  • 68
  • 90
  • 4
    Never optimise anything in any way until (1) you have a performance problem AND (2) you have hard evidence that you are optimising the right things. – High Performance Mark Mar 25 '14 at 13:26
  • In modern C++, inlining has everything to with linkage and nothing to do with performance, so any comparisons to C++ are specious. – ildjarn Mar 25 '14 at 15:49

2 Answers2

5

In my experience, the inline keyword is mainly useful in two situations:

  • It lets you write generic numeric code which would not be possible without inline. So in this case, you need inlining regardless of the performance concerns.

  • I think that generic comparison (see also this SO question) is the main use case where inline significantly improves performance (because the inlined code can be specialized for the current type rather than using generic comparison).

In all other cases, adding inline might make code a little bit faster, but probably won't have significant effect. So I would only use it when you are actually optimizing some bottleneck.

Community
  • 1
  • 1
Tomas Petricek
  • 240,744
  • 19
  • 378
  • 553
  • There's also another option, [like hacking typeclasses onto F#](http://stackoverflow.com/a/8439395/1180426) :) Although I wish there was *some* kind of mechanism for that, I actually wouldn't mind Scala's `implicit`s. – Patryk Ćwiek Mar 28 '14 at 12:16
0

if I happen to reach a bottleneck, when would inlining could be helpful?

This is the method I use to look for speedups.

If I see that the program counter is in the process of entering or leaving a method X or several methods similar to X on a significant fraction of samples, then it could be worthwhile to inline them.

This will only happen on very short methods that don't perform further calls within them.

Community
  • 1
  • 1
Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135
  • When writing code in F#, you also have a very powerful REPL available. So you can use the `#time` directive and measure the performance of functions really easily (provided that your project is organized in a way that makes it possible to load it into F# interactive). – Tomas Petricek Mar 25 '14 at 17:24
  • @Tomas: I'm sure you can. I'm trying not to start flaming about how to do performance tuning, 'cause I think I know how :) Suffice it to say - I think you need percent wall time, not just "time", and it's more productive to take a small number of whole-program, or at least stack, snapshots. (Accuracy of timing is not important, in spite of common wisdom.) Measurements are fine for seeing if what you fixed made a difference - they're not so good for telling you what you need to fix. – Mike Dunlavey Mar 25 '14 at 19:16
  • @Tomas: If I could build an ideal profiler, it would look like this: It would sample at least the stack on wall-time (so as not to miss IO), and possibly data variables as well. Then it would apply artificial intelligence (which I studied) to the samples, looking for arbitrary commonalities in the context of understanding the program. If commonality X is evident on fraction F of samples, that's roughly what it costs. Well, AI is still a future, but the next best thing is between our ears, so that's what I use. Some say "don't you need a large number of samples?" Answer: no, no, and no. – Mike Dunlavey Mar 25 '14 at 19:31