Using Malloc in main vs. passing a stack pointer reference to pass the value of output array

[anujsgithub]

Am I correct to presume that instead of using malloc in main and then passing that pointer to a function to populate it would be quicker to create a normal array and then pass it for allocation as the malloc creates it in heap vs. normal array in main would be created in stack. Is there a scenario where we will have to use malloc and the normal stack deceleration wouldn't serve our purpose?

[cswiercz]

Am I correct to presume that instead of using malloc in main and then passing that pointer to a function to populate it would be quicker to create a normal array and then pass it for allocation as the malloc creates it in heap vs. normal array in main would be created in stack.

I'm not entirely sure what is being asked here. My guess is whether it's faster to use a heap-allocated array within main() or a stack-allocated one.

The answer to that question is: the program tends to access stack-allocated arrays faster than heap allocated ones. For simple programs, you could just stack-allocate your arrays in main() and pass them around to other functions. However, for complex programs it can be unreasonable to always keep around the amount of memory you possibly need at any given time. That is, you might need some temporary heap space for some subroutines which you would free before continuing onto other subroutines.

For example, let's say you have two functions,

void big_computation(... args ...)
{
  // large required memory allocation
}

void another_big_computation(... args ...)
{
  // another large required memory allocation
}

The machine may not be able to store the required memory for both functions but there is enough space for one at a time. In this case, you might want to heap-allocate (depending on the entire program's call structure) so you can free that allocated space for the next part of the program.

void big_computation(... args ...)
{
  // large required memory allocation
  // free before leaving
}

void another_big_computation(... args ...)
{
  // another large required memory allocation
  // free before leaving
}

[quantheory]

Another issue with relying on stack allocation is that your program might not know how big an array actually needs to be at first. For instance, maybe your computation requires regularly reading from data sets of different sizes. It's easy to read the size from a file, malloc a new array of that size, and then read the actual data from the file. But if you insist on keeping an array on the stack, you would have to read the size from a file, then call a function with an array of that size on the stack, and you would have to stay "inside" that function for as long as you needed the data. This makes the program really hard to maintain and understand.

One more thing to think about is that there may not be any benefit. For most programs on most platforms, the stack and heap access speed are similar enough that it doesn't really matter which you use. The time it takes to allocate heap memory is more likely to cause a problem, but even that may not matter much (for instance, if you're reading in a large data set from disk, just reading the data itself will take far longer than the malloc call). So I would use whatever is simplest by default, and worry about performance only if you find out that your program is spending a lot of time in malloc (this is where profiling comes in).

[anujsgithub]

Just to reiterate, if you would like dynamic arrays (with different sizes) in the main program (maybe in a for loop) or you are sure to run out of memory if you don't delete arrays it is better to use malloc.