0

I was just wondering what happens when variable in function scope is always the same and don't change, for example

void test()
{
    int x = 10;
}

I know that compiler stores informations about its name, size etc. but in this case will it cache its value aswell?

My thoughts was if that was a member function that was used like 60 or 140 times per sec. what impact on performance it would have, should it be moved as a member variable to improve performance?

Medievil
  • 1
  • Well in the example shown the variable would be optimized out. So you'll need to test and benchmark. But in most cases favor readable code before microbenchmarks are even considered. – Mgetz Oct 09 '20 at 13:29
  • Don't worry about this. Keep the variables as close to where they are needed as possible. Once you have the code running, recompile it with optimizations turned on, and then profile it to see it's performance. Once you have that data, then you can start looking to hand tuning the code. – NathanOliver Oct 09 '20 at 13:33
  • Making it a member will very likely decrease performance. Local variables of primitive types are dirt cheap and often don't cost anything at all. – molbdnilo Oct 09 '20 at 13:34
  • Actually i have code already, It's in QT and i have drawing of one "more complicated" widget with some local variables at 30-140hz, and thought if it's worth to refactor it to the member variables. Right now everything works great and without any lags, but I have those thoughts like "is it okey?" – Medievil Oct 09 '20 at 13:38
  • 1
    If a variable will not (should not) change, get in the habit of making it `const` (ie. `const int x = 10;`). Not only will it help you catch mistakes, you might also help the compiler figure out optimizations. – Sander De Dycker Oct 09 '20 at 13:49

3 Answers3

1

Except for debug symbols: No, compiler typically doesn't store names of local variables.

Local automatic variables rarely have overhead compared to achieving the same without those variables. To verify whether this is the case in your program, you can measure.

In case of the example function, it is probably optimised into a no-op and there will be no trace of the local variable left.

Member variables cannot be optimised away typically, so adding those unnecessarily can easily affect performance. Whether the effect is significant, you can find out by measuring.

eerorika
  • 232,697
  • 12
  • 197
  • 326
1

Like mentioned in comments if you inspect the assembly generated for such code you will see that the variable gets optimized away (won't even exist in any sense).

If you were to have a function like:

int test()
{
    int x = 10;
    return x;
}

there would not be a variable created either but the compiler would simply have your function return 10.

As for the points about performance unless you already have a measurable performance problem I would not worry at all about "where" your constant is stored.

You will have a very hard time measuring any performance impact.

Helpful links to reasearch this include:

https://godbolt.org/ to try out your code and see the assembly generated (remember to set the compiler flags)

This excelent answer on measuring performance in code: https://stackoverflow.com/a/60293070/567070

OlivierLi
  • 2,798
  • 1
  • 23
  • 30
1

How well this is optimized depends on your compilation settings. godbolt.org allows you to compile code and look at the compiled output. In this example, gcc9.2 compiles your code differently depending on the optimization flags.

No optimization:

https://godbolt.org/z/Ej6ado

The local variable pushed onto the stack, then popped from the stack immediately.

Lowest possible optimization with -O1:

https://godbolt.org/z/dnesvs

The variable mention in your code is completely optimized away, since it isn't used: The function does nothing and returns immediately.

It may be detrimental to make the variable a member variable, since that would in theory allow for it to change between function calls and even during execution of the function. If it is a constant variable, just declare it as 'const' in your funtion and don't worry about optimizations.

MorningDewd
  • 501
  • 2
  • 6