The concept of inlining is great. You essentially get a “free” optimization of your code. For no effort on your part, the compiler can go through and make your code faster. That’s great, you say, inline the whole program! Well, that’s the problem. It isn’t always a good thing to inline your functions. Ok then, I know my program best, so I’ll choose what functions should be inlined. However, if you’re using Visual C++, you can never be certain that the function you have written will be inlined. Raise your hand if you think adding the keyword ‘inline’ to your function will always inline the function? What about ‘forceinline’? Depending on your project settings, both answers are usually ‘no’. (I’ve run into many people that think otherwise).
Ob (In-line Function Expansion)
inline, __inline, __forceinline
Under Visual C++, the compiler assumes that it is smarter than you when it comes to determining which functions can be candidates for inlining. I think this is the way it should be. Remember, I said inlining should be a free optimization. So I don’t want to have to litter my code with a bunch of keywords, which may or may not be appropriate. (What happens if the function gets a lot bigger, now I have to remember to remove the keyword).
Under Visual C#, the ‘compiler’ has perhaps a harder time determining whether or not a function should be inlined. There are 2 chances for determining whether a function is a candidate: During compile to IL, and during JIT. This can be a blessing and a curse. Take a look at this excellent series of blog articles by David Notario, a MS blogger on the JIT team:
Jit Optimizations: Inlining (I) - a simple introduction explaining inlining, what it does, and how it works.
Jit Optimizations: Inlining (II) - whether or not a function is a candidate for inlining.