At first it influences performance. But it may not influence by a number of factors.
A call to a function, in addition to the instructions of deviation and return of the program flow to another address, may exist the copy of the parameters, either from memory to memory, or through registers. So it costs, of course.
If the function is simple and depending on the options used to compile the program the function will be optimized through the call inline Expansion. That is, if advantageous, the compiler deletes the call from the function and places its code where the call was made. Note that the compiler knows that there are cases that using this technique will produce otherwise.
This does the same thing that the macro would do but much better. At first compilers were not able to do this and macros brought this advantage, despite the disadvantages that this feature has. Today there are no more major reasons for using the macro, only very specific situations require its use in C code and even less in C++ code that has even more better features.
It is possible to make macros more complex than simple arithmetic operations but its use is not recommended today. But as I said before macros do not understand the context where they are being executed, this can cause problems if care is not taken in their creation and/or use.
Example:
#define exemplo() \
do { \
faz alguma coisa aqui \
} while (0)
You have no reason to do that today. Today even in C, most of the time the programmer should be concerned with the readability of the code and not with the performance. The compiler will make the code as fast as possible in the vast majority of situations when the code is well written. It is not necessary to look for the best ways to write thinking primarily about performance. When the performance is not enough, then one should think about what to do to improve that stretch. rarely the macro will be the solution to this case.
In almost 100% of cases the compiler will know if a function should be "linearized" for better performance. If he doesn’t do this it’s because he understands that there will be no win and he hits more than the programmers usually do.
It seems to me that some compilers might force the inline, through flag specific, even when not recommended. Almost always when the programmer wants to outsmart the compiler, he misses.
His example is certain to be "linearized" unless the compiler is instructed not to. But a small change that will still make the function short will probably prevent this from happening:
void minhafuncao(){
for (int i = 0; i < 100; i++) printf("Funcao");
}
Probably the time spent within the function is large enough for the compiler to understand that there will be no gain. But other factors may be taken into consideration to make the assessment.
I will not go into details of what is done or not because I do not know deeply and depends on implementation, IE, can change in each version or mark of the compiler.
A test can be applied to see if there is a difference or not:
#include <stdio.h>
#include <time.h>
int minhafuncao(){
int x = 0;
x++;
return x;
}
int main () {
clock_t begin, end;
double time_spent;
int x;
begin = clock();
for (int i = 0; i < 300000000; i++);
end = clock();
time_spent = (double)(end - begin) / CLOCKS_PER_SEC;
printf ("Tempo gasto %.2lf segundos.\n", time_spent);
begin = clock();
for (int i = 0; i < 300000000; i++) minhafuncao();
end = clock();
time_spent = (double)(end - begin) / CLOCKS_PER_SEC;
printf ("Tempo gasto %.2lf segundos.\n", time_spent);
begin = clock();
for (int i = 0; i < 300000000; i++) x++;
end = clock();
time_spent = (double)(end - begin) / CLOCKS_PER_SEC;
printf ("Tempo gasto %.2lf segundos.\n", time_spent);
x++;
}
Behold working in the ideone. And in the repl it.. Also put on the Github for future reference.
The ideone or other site of the type is not the best environment to take the test but you can have an idea. I recommend taking your test. The result may be different under different conditions.
Another test without returning a value. Note how it changes. See working in the ideone. And in the repl it.. Also put on the Github for future reference.
Having the code in a separate function or directly within another function does not influence performance observably.
– pmg
Actually, pmg, depends on the case. Functions that only do, for example, one or two arithmetic operations and that are called loop to heaps can consume a greater and noticeable percentage of time.
– RHER WOLF