The cost of memory to use functions as members when calling a function

Question

This is my first post here.

I know that the question may seem vague, I will try to be clear ...

globally without targeting any interpreted language (well, I am using C # at the moment, but I think the answer should work for others too ...)

I wonder if this type of call makes:

Afunction(var1,var2,AnotherFunction(var3,var2,AthirdFunction(Avector.z)),Mathf.RoundToInt(Avector.x)); 

Will work faster than:

 Type var1 = avalue; Type var2 = avalue; Type var3 = avalue; Type var4 = AthirdFunction(Avector.z); Type var5 = Mathf.RoundToInt(Avector.x); Type var6 = AnotherFunction(var3,var2,var4); Afunction(var1,var2,var6,var5); 

I know that the second method is easier to read, but it works faster, knowing that I will probably call this function broadly (say, in a graphical application, every frame). And as for memory usage, is it better to create more variables to destroy them immediately after using the function or directly encode everything inside the "Affinal" by declaring as few variables as possible ...

(and for understanding: Afunction(), AnotherFunction() and AthirdFunction() already declared elsewhere)

I hope this question does not go beyond the rules of using the forum ...

Answer 1

Assuming a reasonable compiler, the algorithms you use in Afunction, AnotherFunction, and AthirdFunction have a greater impact on performance than anything else you talked about above. Generally, you are worried about what you asked when you have the most effective feature.

In addition, compilers will make built-in function calls, which means you can call

 return_value = fx( A(), B() ); 

But if you look at what goes through to assembler output for your compiler, it may not look like that.

There is overhead when calling a function call, and it is a system and compiler architecture that dictates that it is overhead.

If it was an interpreted language such as awk or BASIC, then the second code block that calls things outside the function linearly will work faster. Rather, it was in 1980 at the DEC PDP.