4

I know that its faster to allocate memory on the stack than on the heap, but why is heap memory allocation slower? Is it because stack allocation is continuous and therefore the issue arises because of cache locality? Is it not the usage of the memory after it has been allocated, it is the time taken to allocate which is slower?

user997112
  • 25,084
  • 34
  • 143
  • 278
  • 1
    This has been allready answered http://stackoverflow.com/questions/161053/c-which-is-faster-stack-allocation-or-heap-allocation – Quonux Apr 06 '13 at 23:22
  • 1
    *General purpose* allocators are slower. There are also [specialized allocators](http://www.altdevblogaday.com/2011/02/12/alternatives-to-malloc-and-new/) (there are many more than those discussed in that post, but it's a very good primer). They can cover most of your needs if you actually understand the memory requirements of your code, while being significantly more effective: faster, more resilient to fragmentation, and more space-efficient. Some are essentially equivalent to the builtin stack, and thus equally efficient. –  Apr 06 '13 at 23:28

2 Answers2

4

Caching issues aside, the CPU stack is just that, a stack, a LIFO list/queue. You remove things from it in the exactly opposite order from the one you put them there. You do not create holes in it by removing something in the middle of it. This makes its management extremely trivial:

memory[--stackpointer] = value; // push
value = memory[stackpointer++]; // pop

Or you could allocate a large chunk:

stackpointer -= size; // allocate
memset(&memory[stackpointer], 0, size); // use

and free it likewise:

stackpointer += size; // free

Your heap, OTOH, does not have the LIFO property. And for that reason it must keep track of all allocated blocks individually. Which means, it has to have some kind of list of free blocks and a list of allocated blocks and it needs to look for big enough blocks when allocating and look for the specified block when freeing and then likely do some block splitting and coalescing in the process. The simple stack does not need to do any of this.

This alone is a significant algorithmic difference between two ways of allocation and deallocation.

Caching and explicit calls to map physical memory into the virtual address space add up as well, but if you consider them to be equal in both cases, you still have a few instructions vs a few dozen to a few hundred instructions of difference.

Alexey Frunze
  • 58,178
  • 10
  • 71
  • 163
3

"Better" may not a good way to describe it, but it usually is "Faster" to allocate memory on the stack, as opposed to on the heap. You are correct that it is the allocation of the memory which is slower, not the use of that memory afterwards.

The reason that heap allocation tends to be slower is that heap managers need to do additional work: they often try to find a block of existing memory that closely approximates the size you are requesting, and when freeing blocks, they typically check adjoining memory areas to see if they can be merged. Stack allocation is simply adding a value to a pointer, nothing more.

Tim Gogolin
  • 96
  • 1
  • 4