Is creating local variables all the time generating extra cost for the software?

Question

Is creating local variables all the time generating extra cost for the software?

Navigation

#1 by (9 votes)

10

I made a program that it writes to variables all the time, and with that I got a doubt, instantiating a variable all the time generates more cost than just assigning the value to an existing variable?

Examples:

Instantiating a variable all the time:

while (true)
{
    int x = 10;
    int y = 30;
    int z = x + y;
}

Using an existing variable:

int x, y, z;
while (true)
{
    x = 10;
    y = 30;
    z = x + y;
}

These examples are just to better illustrate the problem. The program I'm going to apply this is much larger and uses many more variables.

I thought I'd seen a question like this for some time, but today I needed that answer, I did not find it. If you find it, feel free to mark this question as duplicate.

loop c#

asked by anonymous 30.07.2017 / 14:16

1 answer

How does library import work in JavaScript? Which sort algorithm does .NET use by default in a list?

score 9 · Accepted Answer

I've answered this but I do not know where, going to a more specific one.

In this example, has an example that there is a significant semantic change and the code will give different results .

But speaking of cost makes no difference. First, the variable space only exists for it. In the variable is reserved enough space to fit the data of its type and nothing else, no matter how many times it is modified or where or how it was declared, there is only that space.

As a side note, if the variable is by egress, each new assignment is likely to generate a new object, otherwise it is meaningless, and this will swell the heap and put pressure on the GC, which does not is ideal, but if you need to assign new objects you have nothing to do.

From the processing point of view it also makes no difference, the variable declaration is what we call no-op . So declaring out does not bring gains because the cost of declaring in is also zero.

The declaration of the variable in the background occurs at the beginning of the stack frame , that is, when a scope begins all the necessary space is reserved at once, no matter where it was declared. You can change the time of the reservation, but only once. The declaration of all variables of that new scope occurs with a change of pointer ( stack pointer ), does not even matter if it is a variable or thousands of them, the cost is the same, there is only one change in SP.

Allocation always has a cost, unless the compiler can determine that it can be deleted. And the example code has a chance of even occurring since you are doing the same thing and I think you can prove that it does not make sense to reassign the same value without stopping, so that code could be written as

{
    int x = 10;
    int y = 30;
    int z = x + y;
    while (true);
}

Actually the compiler does not:

//reservando espaço para as variáveis
.maxstack 2
.locals init (
    [0] int32
)

IL_0000: ldc.i4.s 10
IL_0002: ldc.i4.s 30
IL_0004: stloc.0
IL_0005: pop
IL_0006: br.s IL_0000

See how was the SharpLab . Even that generates exactly the same code.

But the JITter does even more since nothing is used, it eliminates almost all the code leaving only the movement of the stack frame and loop in the same place:

L0000: push ebp     //protege o BP
L0001: mov ebp, esp //só move o SP para o Base Pointer
L0003: jmp L0103    //fica repetindo sem parar

See the SharpLab .