Printable View
I was reading some literature about some overheads incurred in dynamic memory allocation when the following question came to mind.
What is the difference between how the following two blocks are compiled/allocated/executed..etc ?
ANDCode:while(true)
{
int x[100];
for(auto y : x)
//do something with the values
}
Code:while(true)
{
int *x=new int[100];
for(/*100 times*/)
//do something with the values
delete[] x;
}
The first snippet allocates the data on the stack, usually, and the second on the heap. Allocating memory on the stack is easy: simply subtract the size from the stack pointer; you automatically release it after each function by restoring the old pointer. However, stack space is usually limited in both size and lifetime, in the same way you can't return pointers to local variables.
On the heap you can allocate and deallocate data whenever you wish. There's usually loads available, but allocating and deallocating is relatively slow.
There are actually three places to allocate array: On the stack, on the heap, and on the data segment. Each have advantages and disadvantages.
The stack Is used for most function local variables, including parameters and return values, and some additional meta data involved in calling functions. It is limited in size, and so holding large array can cause your program to "stack overflow", which is generally not a recoverable exception. Having deep recursion can also cause your stack to overflow.
The data segment is used for local-static and global variables. It's size is determined readily by the sum of all your global and static variables rounded up to the kilobyte or so. You can allocate large array here, but you only get what you asked for: you can't create a global variable at runtime, nor can you remove variables you don't need.
The heap is the additional memory that you can add to your program at any time using operations like new. The heap is allocated in large chunks, but operations like new will delegate small, reusable portions. Getting a block allocated can be slightly costly, but getting a portion of a previously allocated block isn't. The heap is limited by the other programs running, any memory quota restrictions by your operating system, and by the address space of your operating system (and processor). A program can generally ask for a lot of heap memory if it needs it, though memory space is not unlimited.
Generally, speed is not the factor in deciding between these three. Speed is chiefly impacted by how near you memory accesses are to each other. To write fast memory intensive code, you want to try to put the frequently accessed data together.
EDIT: I should mention that this only applies to modern operating system setups. Ancient operating systems and microcontrollers are different.
So, w.r.t the second snippet, the time for allocating an array of size 100 is always less than 100 times the time for allocating one variable ?Quote:
The heap is the additional memory that you can add to your program at any time using operations like new. The heap is allocated in large chunks, but operations like new will delegate small, reusable portions. Getting a block allocated can be slightly costly, but getting a portion of a previously allocated block isn't. The heap is limited by the other programs running, any memory quota restrictions by your operating system, and by the address space of your operating system (and processor). A program can generally ask for a lot of heap memory if it needs it, though memory space is not unlimited.
Or are there better ways to access the remaining portion of the 'blocks' you mention?
Well allocation one variable 100 times with new involves calling new 100 times. Allocating an array calls it once. The first of those 100 allocations will be as slow as allocating the array, the rest will be faster. But Again, this isn't where you optimize for speed.Quote:
Originally Posted by manasij7479