4

No I'm really serious.

I've just witnessed someone move variables local to a function up to global status, with the commit message "Relieve the stack".

Is there really some rationale towards doing this sort of thing?

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
lindelof
  • 34,556
  • 31
  • 99
  • 140
  • related [C++ performance of global variables](http://stackoverflow.com/questions/2867363/c-performance-of-global-variables) – Nick Dandoulakis Feb 04 '11 at 14:22
  • The (potentially more-important) question is: Will working with global variables help your sanity? – Dan J Feb 04 '11 at 19:23

6 Answers6

10

First, putting variables in global variables doesn't improve CPU usage directly. Stack initialization is generally a single add/subtract at function entry/exit, independent of stack frame size.

However, if the function requires a very large working set, it's better to put it in something other than stack; the stack's size is usually rather limited. The usual choice is the heap; however this does take time to allocate and free, and so if you're going to be calling the function frequently it can be expensive. It's also a problem on embedded systems, where they may not have a proper heap implementation.

So if heap is a problem, globals can be a solution. However, they have their own downsides - in particular, you don't want to have multiple threads messing with the global data at the same time, nor can you recurse through this function without taking a lot of care, or the recursed bits may corrupt the earlier calls to the function.

So it's a technique which, in some cases, can be helpful. I wouldn't recommend using it as a first choice however, because of threading issues.

Also, for what it's worth, you can get the same memory effects with static variables. I would recommend using these instead, as otherwise you'll end up polluting the global namespace.

bdonlan
  • 224,562
  • 31
  • 268
  • 324
  • @Nick, what do you mean by that? The stack frame allocation is an implementation detail. You can have a variable initialized deep in a loop somewhere, but the compiler might choose to allocate sufficient stack space for it in a single stack pointer adjustment in the function prologue. However, it doesn't need to _initialize_ that memory until later. – bdonlan Feb 04 '11 at 14:31
3

There is this myth around that global variables make your program "faster". That's crap.

However, if you use a large static array, you may want not to put it on the stack to prevent the risk of a stack overflow. The stack memory is considerably small compared to overall logical memory space.

In a well-designed program that is larger than 100 LOC you may want to use other ways of allocation for your huge data: putting it into an object (std::vector etc.) or using malloc/free, new/delete.

ypnos
  • 50,202
  • 14
  • 95
  • 141
  • 1
    Might be true for PC programming, which the OP didn't mention. From a general C programming point-of-view, it is no myth. I also reckon the OP will get problems getting std::vector running in their C program. – Lundin Feb 04 '11 at 14:24
  • So tell me which architectures out there make this a non-myth. It is quite lame to nitpick that I mention C++ stuff next to C stuff. – ypnos Feb 04 '11 at 16:05
  • 2
    @Lundin: The only way it's not a myth is if your compiler is utter crap, in which case you could probably write a new compiler that does better as a weekend project... – R.. GitHub STOP HELPING ICE Feb 04 '11 at 18:58
  • 1
    Your comment speaks of ignorance to the world outside your PC desktop. PCs aren't the only computers in the world. In fact, you probably have around 100 computers in your possession that aren't PC:s. If you don't know jack about microcontrollers, you probably shouldn't comment on their calling conventions or stack usage. – Lundin Feb 06 '11 at 20:08
0

If the variables were declared static there is probably no difference.

If they were not, then there will be less stack pushing and popping, but the behaviour of the program might change.

Benoit
  • 76,634
  • 23
  • 210
  • 236
0

Using global variables instead of function parameters will reduce the needed stack space for calling the function. That is probably where that comment originated from. But as all global variables live throughout the whole duration of the program, the overall RAM consumption of the program will be higher.

This is no myth, many kinds of systems have sluggish stacks. The effect will far less notable on a PC or other such high-end 32/64 bit CPUs (nothing in the original post indicates PC though).

Global variables instead of parameters is usually very bad practice however, as it leads to spaghetti. To avoid that, such variables should be declared static.

The best practice to reduce stack space when calling a function is inlining, if you have that option.

Lundin
  • 195,001
  • 40
  • 254
  • 396
0

If you're worried about stack overflow in recursion, and global variables could solve your problem, there's a much better solution: put all variables in a struct in the outermost wrapper function for your recursion, and pass a pointer to that struct to the actual recursive function. This approach gives you all the benefits of global variables, and none of the disadvantages.

Also note that on modern systems with position-independent code and shared libraries, accessing global variables is often significantly slower than accessing local variables or accessing members of a struct indirectly through a single pointer, due to the costs of GOT-relative addressing and similar.

Don't use global variables unless you really need to have global state, and even then, try to eliminate it. Never introduce global variables as an "optimization".

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
-4

Is there really some rationale towards doing this sort of thing?

No.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • @bdonlan I would have thought the onus on providing justification should fall to the person attempting to *relieve* the stack. – David Heffernan Feb 04 '11 at 14:12
  • 5
    Perhaps, but the OP wants to understand why this may or may not be a good thing. Just saying 'No' doesn't help them understand - and that's the point of this site; to build understanding, not to simply answer the question as literally asked. – bdonlan Feb 04 '11 at 14:15
  • @bdonlan In order to do that you have to be able to read the mind of the *reliever* which is stretching it a little, although you seem to be able to do it. Perhaps I just need to be as good at mind reading as you are. – David Heffernan Feb 04 '11 at 14:25
  • On the other hand, this does present an opportunity to achieve "Peer Pressure"!! – David Heffernan Feb 04 '11 at 14:27
  • This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. – Neeku Jul 24 '14 at 09:39
  • @Neeku It does answer the question that was asked. Sometimes the answer is simply yes or no. – David Heffernan Jul 24 '14 at 09:42