Hi, what''s faster, allocating an array statically inside a function ( double thearray[32] ), inside a function using new ( double *thearray=new double[32] ) and then delete it at the end of the function, using a global variable: double thearray[32]; void f(){ (... use it here ...) }; And also why of course... Thanks in advance.

if you are using a global variable, then it is statically allocated, meaning at compile time. It would therefore be faster, as it would already be allocated when the program first runs. just to be sure put the static keyword in front of it.
One thing to be careful of though...that name will then be in the global namespace, so you might want to do this if it is in c++

namespace{    static double thearray[32];} 

this will create an anonymous namespace, which has only file scope, and will prevent namespace pollution.

I would not recommend the usage of global variables at all, only when its absolutly no other way. I consider massive use of global variables as bad programming, especially if you program c++.

While it might not seem to be wrong to use them in small programs, once your project gets bigger and more complex, global variables can become a source of ugly and hard to debug problems. Sooner or later you will lose track about all the places where you used that special variable.

About wether to use static or dynamic allocation inside a function, i would use static allocation over a new/delete in functions that are used alot. But keep in mind that if you use multithreading, this can lead to race-conditions.

The global var is the fastest one. Beacuse it has the place in the .exe file and so, when the OS loads the .exe into the memory and runs it, there's a place for you variable. But as schue said - don't use it.

The stack (double thearray [32]) is slower than the global var, but faster than the new allocation. It simply substracts 256 from the esi and there's place in the stack created, ready to use. But, you might very easily get into the stack overflow, since it's not unlimited, and stack overflow is very horrible and painful bug.

The heap (double *thearray = new double [32]) is the slowest one. The program asks the system for some memory. The system then searches the memory to find some. When it's found, it's returned to your app. And when you stop using it, the app asks the system to mark it as free (the stack version, just adds 256 to the esi, removing the allocated space in one instruction). There's also a chance, the system doesn't give you the memory and then, you're in trouble, you have to solve. Also - using new and delete very often may lead to the heap fragmentation, causing next calls to new being very slow, or unsuccesful. But, at least, it doesn't cause stack overflow.

I would recommend you to use the stack version, if it's no too large. Or use the global var, if you don't have too many of them.

Oxyd

- Unreadable code is code written on a piece of paper, but not the one, in which the programmer is using a space in the place you don't.
- Real programmers aren't afraid of goto

[edited by - Oxyd on May 29, 2004 9:44:14 AM]

Ok, thanks, i also noticed that if i declare variables at the beginning of a function it''s faster than when i declare them inside the scope of an if statement, why is that? Because the memory is only allocated then in a slower way because it''s not always needed (or are variables in the scope of a function allocated on startup)?

The variables (stack ones) are created when you enter the scope. In C++ you may declare them wherever you want in the scope, but they exist since the entry of the scope:

void foo (){  doSomething ();  doYetMoreThings ();  int variable;  //<- here, the variable is declared                 //but exists since the '{'  somethingWithTheVar (variable);}    

And so, if you code "if (...) {" Then you create new scope (each '{' creates new scope) and so, new space on the stack must be created (and at the end it is destroyed). So if you have the 'if' inside some loop, the vars inside its scope are created and destroyed constantly, resulting in performance loss.

for (int i = 0; i < 10000; ++i) {  if (i % 2) { //if it's even    int var = i * i;    doSomethingWithTheResult (var);   }}    

This code constantly creates and destroys 'var' (5 000 times). If you put the int var before the for statement, it would be created only 1 time, which would be somewhat better.

Oxyd

- Unreadable code is code written on a piece of paper, but not the one, in which the programmer is using a space in the place you don't.
- Real programmers aren't afraid of goto

[edited by - Oxyd on May 29, 2004 12:47:38 PM]

[edited by - Oxyd on May 29, 2004 12:48:47 PM]

[edited by - Oxyd on May 29, 2004 12:49:30 PM]

Hi Oxyd, so I thought about what you wrote about the variable being allocated in the scope of the block statement {}. I thought that most modern compiliers optimize the code so that variable is properly allocated in the stack without the need for continuous allocation/de-allocation.

Anyways, I tested a for-loop code on MS VC++ 6.0 and found that there is virtually no difference in speed.

- Steveo

Oh, i think i meant that doing this:


for ( int i=0;i<100;i++){
//blablabla
};


is slower than:


int i;
for ( i=0;i<100;i++){
//blablabla
};


And that's something i still don't really get, it's probably because when variables are allocated there are certain tasks to be done before and/or after the allocation which only have to be done once when declaring the variable together with others at the beginning of the function. It does make a difference for sure (i tested it in release mode (maximize speed opt) and my app went from 89 to 92 fps when i replaced 2 variable allocations from statements to the beginning of the function scope, i know that framerate doesn't say much but is does say the difference is there).

Quote: Original post by Oxyd

The variables (stack ones) are created when you enter the scope. In C++ you may declare them wherever you want in the scope, but they exist since the entry of the scope:

Errm, I think you'll find this is horribly horribly wrong.
C++ doesnt construct a varible until it is used, which is a good plan as it can delay costly object construction until such time as it is needed, instead of constucting all the objects up front and having to destory them anyway even if you never use them.
Thus why you should delay declaring and constucting objects for as long as possible in C++ (iirc its one of the tips in either Effective C++ or More Effective C++).

With regards to the APs comment:
Objects are constucted/destory'd apon entry/exit of blocks in the majority of cases, namely things which are non-trival. For example you might be using a class in a loop which is allocated and adjusted as such when the loop finished the object has to be destoryed correctly and remade at the start of the next loop.
Granted, for things like int, floats, chars etc if MIGHT be able to get around it, depending on how its used, but for more complex objects the scopeing rules apply.

Quote: Original post by _the_phantom_
C++ doesnt construct a varible until it is used

If that's true i really really DON'T get the speed difference between the examples i gave above.