Which is faster:
* creating an object statically (ex. MyObject object(foo); )
* creating an object dynamically (ex: MyObject *object = new MyObject(foo); )
If creating an object dynamically is slower, how much slower is it?
Thank you!
Printable View
Which is faster:
* creating an object statically (ex. MyObject object(foo); )
* creating an object dynamically (ex: MyObject *object = new MyObject(foo); )
If creating an object dynamically is slower, how much slower is it?
Thank you!
Run a test and let us all know. ;)
Todd
creating it dynamically is slower because of memory management (allocation). Statically allocate something takes no time AFAIK (except the time spent in the constructor).
As for how much, that depends on your system's memory management implementation.
By "statically" I see you simply mean as a local variable.
The rule is: Don't use 'new' if you don't need to.
That's not true.Quote:
Originally Posted by cyberfish
The actual time it takes to create an object depends on how the application manages memory in its address space, and that depends on compiler/library implementation, the operating system, and the actual resources available to your program. Creating any object requires some memory to be obtained or supplied. The only thing that changes is when it happens, and what section of memory (eg what segment) the memory for the object is obtained from.
Statically allocating something means that is created before the first time it is used (i.e. a global object) which is a different thing from Darkwraith's first example.
The relative speed of different mechanisms of creating an object is implementation dependent. There is no universal guarantee that any particular mechanism is faster. In practice, a static allocation is often faster because the compiler/linker can do some work to optimise things. There are also some optimisations a compiler can do with the process of creating an object locally to a function. However, there is still no universal guarantee that any option for creating an object will always be faster than another.
For tiny objects, the overhead of allocating memory can be substantial. For large objects, the time used for constructing the object is much greater, so the allocation disappears in the noise. Obviously, somewhere in between are "medium sized objects", where the allocation and construction takes about the same amount of time.
Ok, so for the pedants in this forum: Actually, the size of the object itself is technically irrelevant, the time the constructor takes is much more important - consider this:
As iMalc says: If you don't need to use new, then don't. The trouble is of course "knowing" when you need to use new...Code:// Small object, slow construction.
class slowconstructor
{
public:
slowconstructor(int n) {
f = 1.0;
for(int i = 0; i < n; i++)
f = f * i;
};
private:
double f;
};
// Large object, fast constructor.
class fastconstructor
{
public:
fastconstructor(n) {
len = 0;
}
private:
int array[100000];
int len;
};
The problem with NOT using new is that the code uses up stack-space, which is more limited that free-storage (heap-space). The heap, in a modern OS, can be more than a gigabyte. Whilst there is no technical reason why the stack can't be huge too, it's normally limited to a few megabytes. Running out of stack is also "worse" than running out of heap-space, as it's impossible for the code to recover from a "out of stack" scenario - out of heap can be detected and at least some sort of resemblance of recovery is possible.
Obviously, real-time OS's may be even more constrained when it comes to both stack and heap-sizes, but generally, the heap is a much better place to put "large" objects.
Finally, there is one other consideration: If you use a pointer, the compiler will have to dereference the pointer to get to the actual object. This can lead to further reduction in performance - again, more noticeable on objects where the member variable or member function is "trivial" and disappears of the member variable or member function requires a lot of CPU-time to get the work done.
--
Mats
The stack has the guarantee that objects are deallocated in reverse order of their allocation, while the heap must support any order of allocation/deallocation. That makes the memory management for the stack far, far easier than for the heap, and thus faster. (The management of the stack is a single pointer in pretty much every piece of hardware out there. The management of the heap is subject to much research and use-case-specific optimization.)
> Which is faster:
Does it matter?
The first rule of optimisation is to make it right, before you think about trying to make it fast.
Use the form which is most correct in the circumstance in which you're using it.
Besides, as matsp demonstrates, there is no single clear-cut answer to the problem.
Further to matsp's comments on the stack, consider that growing the stack by a large amount can cause a large number of page faults. IIRC, windows grows the stack 4K at a time when it's necessary to do so, up to however many pages are needed to satisfy the local stack frame. However, this only happens once, so when you've got the large stack, there is no further hidden cost. How stacks grow in other operating systems (if at all) is left as an exercise for the reader ;)
Well, allocating a large amount on the heap can cause a large number of page faults too. IMO when comparing stack vs heap allocations there is really a clear cut answer if you know there is hardware support for the stack. The stack will be faster....Quote:
Originally Posted by Salem
It gets shady when there is only software support for allocating stackframes because the obvious way then is to allocate so called "activation records" dynamically...
>> Use the form which is most correct in the circumstance in which you're using it.
In cases where both will work, the local variable is almost always the most correct choice.
Thank you for all your help!
This pretty much answered my question.