static class variable vs. global variable

I believe I understand most of the negative impact that global variables have on a program. One major issue is their negative effect on your program's performance.

I am at a point in my program where I don't see a way around having a private static variable in my class. However, I am concerned on how this will effect my programs speed.

Isn't a static class variable, in a sense, a global variable?
Also, do static class variables (public or private) have the same negative performance effect on a program as a normal global variable?

Thanks in advance for your replies and knowledge!

globals dont have a negative performance effect. in fact they have quite the opposite. There are lots of problems with globals but performance isnt usually one of them.
Why do you think that a global or a private static member will cause you performance troubles? Those sort of problems are usually caused by poor algorithms.

Global variables, as Stoned_Coder said, don't affect your program's performance.
They're frowned upon because they tend to introduce name clashes and alot of coupling of functions that use that object. If you removed that global object later, all the functions that use it internally will have to have their definitions modified. Whereas if the object was just passed to them via a pointer/reference, only the passing lines need to be removed.

Well, non-c++ class globals do indeed affect performance. If the variable isn't global, then functions have to pass it around as argument. It takes processing time to push variables on the stack before function call then pop them back off after function call. Years ago when cpu speeds were very slooooow that was a very big deal, so we used globals to eliminate that slowdown in time-critical applications. Today, when lightning-fast cpus there is almost no difference, but the difference is there nonetheless.

The difference between non-c++ class static variable and a static variable of a class is scope. A c++ static class object is always preferable over non-class global because the class name limits the scope (or namespace if you will) and there is rarly, if ever, a chance of multile definitions of objects with the same name.

Hmmm... I guess I believed globals decrease performance because that was what I was always taught and read in books.

Here is a quote from one of my c++ books (2 years old):

Quote:

---

Programs written for 8- and 16-bit architectures often make extensive use of global and static variables rather than local variables. This was done for performance reasons because such architectures typically provide a very limited number of registers. Unfortunately, when such code is executed on today's register-rich architectures it may substantially decrease performance by forcing the processor to access memory every time it reads or updates a variable value.

---

This is just one example from just one of my books... doing a quick search on google I am also seeing similar results.

So I guess all of you are saying this information is outdated now and either the new compilers or the new processors handles globals with no performance loss?

Thanks for everyone who gave input, however, now I am really confused with all the conflicting information. :confused:

I think you need to get a different book -- that quote is nonsense. PCs Intell and Intel-compatible Pentium CPUs have only a couple more registers than did the old 8088 computers. The number of registers have (almost) not changed, its the size of the registers that's changed.

Access time to fetch the value of a global integer is nearly the same as a variable on the stack. Its not access time problem, but the time to pass variables from function-to-function, which also increases stack usage.

Quote:

---

by forcing the processor to access memory every time it reads or updates a variable value.

---

That is just plain wrong. Its implementation defined, which means compilers are free to do it however they wish. But true when the "volatile" keyword is applied to a variable. but even in that case, the processessor has to fetch the variable's value every time whether the volatile variable is global or local.

Here are few results from a quick google search:
http://www.codeproject.com/cpp/C___C...timization.asp

http://publib16.boulder.ibm.com/pser...fplanning4.htm

http://www.techonline.com/community/..._content/20437

...

... I could keep pasting hundreds of links here

Regardless, you should be making the decision based on what is the clearest and most effective design choice. If your program is too slow, and your profiling shows that the private static data is causing the slowdown (highly doubtful), then by all means look into something else.

If you are attempting to optimize a program, looking at the differences between global and local variable access time will be pretty-much fruitless and a waste of efforts. Put your efforts in big-money areas such as function algorithms. Interesting to haggle about a couple clock ticks, but not really very practical.

Very true dave... However, I would rather find out the truth on this issue than integrating the private static variable into my code and finding out it's too slow and having to re-write everything.

So I guess I have two separate questions:

1) Do globals decrease performance? (which, so far, everyone has said NO)

2) Then, if they do:
Isn't a static class variable, in a sense, a global variable?
Also, do static class variables (public or private) have the same negative performance effect on a program as a normal global variable?


Thanks

Ancient Dragon: I agree completely about the "function algorithms". However, I am not writing a simple "hello world" application. I am trying (and having fun) to write a very complicated calculation program that could run for hours. With all of the loops, nodes, and trees (kind of like a chess program) a few clock tics everytime it accesses my variables could make an enormous difference.

What are your alternatives to a private static variable? If the alternative is a separate member for each instance, then that would most likely be worse. If you have ideas for other alternatives, you can figure out if any of them make the private static idea a pessimization worth removing.

Function algorithms are even more important in your program than I originally mentioned. If you are running the program on a PC such as Pentium, it still won't make much difference because of the CPUs very limited number of registers (there are only 4 general-purpose registers, eax ebx ecx and edx. Two others esi and edi are often used as loop counters). So you see that only in very tiny loops will the program be able to load a value in a register and keep it there. Between function calls, the C and C++ compilers I used only saved esi and edi -- all others are subject to be changed. And that means when a function returns the program will have to reload variables anyway.

As for the register keyword -- modern compilers ignore it.

I wrote two simple programs.... one using globals and one using local variables with pointers.

The global var program ran about twice as fast as the local var program on my cpu.

Code:

---

//globalTime
#include <iostream>
#include <ctime>

void calcTwo( void );

//globals
long double One, Two;

using namespace std;

int main ( void )
{
  long double start, end;

  start = clock();

  for( One = 0; One < 1000000; One++){
    calcTwo(); 
  }

  end = clock();
  cout << ( (long double)( end - start ) / (long double)CLOCKS_PER_SEC ) << " seconds" << endl;

  return 0;
}

void calcTwo(void){

  Two = (One * One * One + One) / (One * One + One);

}

---

FreeBSD # ./globalTime
0.03125 seconds

Code:

---

//localTime
#include <iostream>
#include <ctime>

void calcTwo( const long double * One_ptr, long double * Two_ptr );

using namespace std;

int main ( void )
{
  long double start, end, One, Two;

  start = clock();

  for( One = 0; One < 1000000; One++){
    calcTwo(&One, &Two);
  }

  end = clock();
  cout << ( (long double)( end - start ) / (long double)CLOCKS_PER_SEC ) << " seconds" << endl;

  return 0;
}

void calcTwo( const long double * One_ptr, long double * Two_ptr ){

  *Two_ptr = (*One_ptr * *One_ptr * *One_ptr + *One_ptr) / (*One_ptr * *One_ptr + *One_ptr);

}

---

FreeBSD # ./localTime
0.0625 seconds


They both ran faster if I took out the function call and did the calculation in main()... but the global var program was still about twice as fast. I am not sure if this was a good representation of a global program vs. a local program or not... but it was interesting.

both programs ran in the same time with VC++ 6.0 compiler in release mode on XP os. Maybe your compiler didn't optimize the code very well.

Quote:

---

I believe I understand most of the negative impact that global variables have on a program. One major issue is their negative effect on your program's performance.

---

nadom7, yeah, it might be just a latency issue, though. Perhaps the program access local data quite a lot, but the global and static data that must stored in a different page it doesn't. In some situations, not using globals could be faster, but if you'll passing a lot of data round as parameters using globals could be faster. But I wouldn't worry too much about it. I'd just go for clarity first.


Another issue with globals, I think, is a compiler that doesn't optimize outside of functions will have trouble optimizing somtimes. For example, say you have

Code:

---

int globalVar;

void f()
{
      int c = 0;

      globalVar ++;
      globalVar++;
      g()

      c = globalVar + 5;

      printf("c = %d\n", globalVar);
}

void g()
{
      printf("global var = %d\n", globalVar);
}

---

Then, for such a compiler, it'll compile code to have to load globalVar into a register in f() before the call to g() but unless if the compiler can detect that g() doesn't modify globalVar, it'll likely have to reload globalVar into a register.

Quote:

---

Function algorithms are even more important in your program than I originally mentioned. If you are running the program on a PC such as Pentium, it still won't make much difference because of the CPUs very limited number of registers (there are only 4 general-purpose registers, eax ebx ecx and edx.

---

Ancient Dragon, Pentium 4 has registers that are not visible to the assembly programmer. These latter pentiums are also RISC, and they, as I've been told, translate the very complex instructions into simple instructions that likely use hidden registers. They also have registers for floating point, operating system control, paging, MMX, etc so the number of registers in the latter processers has gone up quite a lot.

Thanks for all the input on this subject.

okinrus: I believe you are correct in your example showing that the global will have to be reloaded.

Ancient Dragon: You are correct in that I did not have my optimizations set correctly at all. After optimizing both of my example programs ( i believe correctly ) I received very different results. I was able to get the global var program's time down to 0.0078125 seconds! However the amazing thing is... after correctly optimizing the local var program it will only output 0 seconds! I have to add a few more function calls to the local var program to even get it output anything but 0 seconds. After adding two more functions I did get it to output 0.000315!!

The optimizer may have made the function inline, then optimized the loop out altogether, but you'd have to see the assembly code to confirm.

Quote:

---

Originally Posted by Dante Shamest

Global variables, as Stoned_Coder said, don't affect your program's performance.
They're frowned upon because they tend to introduce name clashes and alot of coupling of functions that use that object. If you removed that global object later, all the functions that use it internally will have to have their definitions modified.

---

I have had that problem you talk about. But I figured out it has to do with the way you asign your vars. Not the way you declare them. As an example, it happens a lot when ever I asign FALSE to an int var and there is a BOOL declared right under that area that the int was declared.