Directly execute or through functions?

[Putarda]

Because I'm working on my game engine called Light Speed Engine (my private), my first priority is speed. I was always wondering which way is faster?

int func() {

    return 3 + 2;
}

int i = 3 + 2;

std::cout << i; //this
std::cout << func(); //or this 

Or in other case:

bool minefunction() {
		
	return notminefunction() + 3 == 4;
}

if (notminefunction() + 3 == 4) { //is this way faster
	//something
}

if (minefunction()) { //or this
	//something
}

[mbozzi]

I think the first form (no function call) is potentially faster with no optimization enabled. I might be wrong, I didn't check: which version you use probably doesn't matter.

There are 4 steps (guidelines) to optimizing code. These steps should be used if and only if your code actually has a performance problem:

Step 0: Verify that you're asking your compiler to optimize your entire program.

Step 1: Use a profiler to locate the offending code. In most cases, 90% or more of execution time is spent in a single method or group of methods. Only the offending code should be optimized.

Step 2: Analyze the time and space complexity of the offending code. Try to improve it by asymptotically reducing the time/space complexity of your program. Consider trading space for time, or switching to an algorithm that is tuned to handle data similar to the input. This is the step where you should reconsider your approach to the problem. Try hard to seek improvements here, rather than proceeding to lower-level optimizations. After this step, stop if your program is now fast enough.
You can expect asymptotic improvements in time/space in the optimized code, if such an optimization is applicable.

Step 3: Look for low-level optimizations like SIMD extensions to get factor of N performance improvements in hot spots, and for opportunities to parallelize your program. Stop if your program is now fast enough.
You can expect small constant integer factors of improvement (e.g., 100% speed-up) in the optimized code in some cases.

Step 4: Make micro-optimizations in the calling code, e.g. eliminate branches, make the code more cache-friendly, and unroll loops. Stop if your program is now fast enough.
You can expect percentage-wise improvements (e.g., 5, 10% speed-up, potentially more) in the optimized code in some cases.

If your program is still too slow, repeat for another bottleneck!

Of course these are just guidelines, but these are generally solid guidelines for fixing performance problems.

The key point is that you should not optimize unless it is necessary.

[raschupkin]

Most compilers can optimize code, and will make these functions inline. You can also use 'inline' keyword to force such optimization. Anyway difference between your cases will only matter when such code executes very often(tens thousands times a second).

[mbozzi]

The inline keyword does (did not) not force a function or variable to be inline; it's just a hint, similarly to the original meaning of register (i.e., to place the primitive variable in L0 cache -- a processor register), which now means "automatic storage duration" and is deprecated, removed since C++17.

Since C++17, inline means that multiple definitions of a variable are function are allowed in multiple translation units. The new intent of the keyword is to help create header-only libraries.

You can usually force inline function expansion using a implementation-specific attribute. That's
always_inline for G++ and __forceinline (IIRC) for Microsoft's compilers. For details when this is not possible, read the documentation for your compiler.