Author: Bruce Moreland
Date: 15:58:50 10/26/01
Go up one level in this thread
On October 26, 2001 at 17:05:06, Tom Kerrigan wrote: >On October 26, 2001 at 16:56:19, Derek Mauro wrote: > >>As far as I can tell, static and global variables seem to be equally efficient, >>the only difference being that statics have a limited scope. Am I right, or is >>one actually more efficient than the other? Is there any advantage to passing >>around a static or a global? I've always read that globals should be avoided. >>Is there any performance reason why? >> >>Thanks for your help in advance. > >I assume you mean static -> local. (?) He's talking about the static attribute. Inside a function, you can use this to essentially make a variable a global, but which is only available to the function. Outside a function, "static" means that the name of the thing (a function can also be static) isn't available to the linker, so it can't be used from other modules. There is some use for "static" inside functions. Outside functions, the wimpy name-hiding aspect of the static keyword is useful but not hugely so. >In the olden days, local vars were allocated on the stack (usually fast) and >globals were in the heap somewhere, possibly other segments (very slow). >Registers were also not allocated for globals (extra slow). Automatic variables (locals) can't be addressed outside of a function, unless you pass the address to something. This means that the compiler can easily understand everything about them and enregister them. It is also possible for the compiler to twist around the internals of a function such that some automatic variables are completely removed. The variables amount to suggestions to the compiler. The compiler can do whatever it wants as long as the job you specify gets done. Globals are declared outside function scope, and compilers are not meant to optimize that kind of thing. >These days, it doesn't really matter where your variables are located in memory >(caches are great!) and registers are allocated for anything. So it shouldn't >make a difference. Realize that there may be overhead for passing variables >between functions; most compilers can do fast calls, where arguments are put in >registers instead of the stack, so this is often a wash, too. It matters tremendously where things go. Local variables are easy to maintain, they don't take up any permanent space, and they don't often cause weird side-effects. They are fundamentally good, because they allow you to stick a function in your head, screw with it, then stick it back into the source file without wrecking the rest of your world. Globals should be regarded as evil, because they are. They are harder to figure out and deal with, they make it harder to reuse code, and they are the root of a lot of bad bugs. A program with a lot of globals is like a bucket-full of partially eviscerated mice. It's messy, it's hard to figure out what goes where, and nobody wants to deal with it. bruce >Basically, program in the way that seems the most straightforward to you and >it's a safe bet that it will be fast. No harm in trying things multiple ways, >though, of course. :) > >-Tom
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.