3

Say that I have the following situation:

void myFunc()
{
    int x;
    //Do something with x
}

"x" is placed on the stack which is no doubt fast.

Now, "myFunc" is called very frequently, lets say 10 times per second. Is it plausible to do something like this:

int x;
void myFunc()
{
    //Do something with x
}

so that x gets allocated in the applications data segment. but it is allocated only once. Since "myFunc" is called so frequently, does the second approach deliver any performance benefits?

  • In your example x is stored in the applications data segment, not on the heap. – Gábor Angyal Feb 6 '15 at 8:58
  • 1
    possible duplicate of Why is Global State so Evil? – gnat Feb 6 '15 at 8:59
  • 2
    @gnat The question you linked focuses on design aspects of global variables. What I wanted to know more about was the performance aspect. I could not find such an answer. If you are aware of one, please do mark it. I will try to place more weight on "performance" in my question. – Nitkov Feb 6 '15 at 9:03
  • 1
    your explanation makes me feel more and more that this is XY-problem. It's like looking for blanket justification to get into extremely dangerous code when things should indeed work opposite - jou just don't get there unless you have a hard proof that this is the only option. And no, saved processor ticks don't qualify. In one of past projects we were counting every tick, including even being forced to use macros to save on function calls, and in there, it was simply forbidden to declare variables that way, because that's way too dangerous – gnat Feb 6 '15 at 10:23
  • 1
    These days, 10x/second may not qualify as 'frequent' :-) – Dan Pichelman Feb 6 '15 at 15:21
16

Allocating a variable on the stack and deallocating it is a simple addition and subtraction of the stack pointer. Given that it happens anyway when entering a function means that local variables are so cheap that trying to optimize them to anything else will generally incur more cost.

Putting it in the data segment will incur a cache cost, the stack will usually be in cache.

The biggest disadvantage is that you lose reentrant properties. Meaning that recursion won't work and that it's not thread-safe.

The other big disadvantage is that letting the variable escape scope is that the optimizer can't make it a register-only variable, which never reaches RAM to begin with.

  • 9
    Just to make the conclusion more obvious: Promoting a local variable to a global is likely to make the code slower, not faster. – Sebastian Redl Feb 6 '15 at 11:11
3

It also depends on the architecture. In ARM the first few locals are stored in registers only. As long as you do not call any other functions then these will never go on to the stack.

You need to go the opposite direction. Rather than using globals you should start by limiting the scope if the variables as much as possible. Not only is this good coding practice but it also helps the compiler to better optimize your code. You should compile with maximum speed optimization then look at the generated assembler code. Even better is to step through this code if your IDE will show you the ASM at the same time as the C code. You will be surprised at what the compiler can do. See here for a good discussion: https://stackoverflow.com/questions/15180309/local-variable-location-in-memory

Only after you have good readable code that had been optimized by the compiler should you start looking at custom hand coded optimizations. Normally this is only needed for special real-time applications with very strict time constraints.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.