How to Choose Heap Allocation VS. Stack Allocation in C++

How do I choose heap allocation vs. stack allocation in C++?

One of the C++ features that sets it apart from other languages

... is that you have to do memory allocation manually. But let's leave that aside:

• allocate on the heap when an object has to be long-lived, i.e. must outlive a certain scope, and is expensive or impossible to copy or move,
• allocate on the heap when an object is large (where large might mean several kilobytes if you want to be on the safe side) to prevent stack overflows, even if the object is only needed temporarily,
• allocate on the heap if you're using the pimpl (compiler firewall) idiom,
• allocate variable-sized arrays on the heap,
• allocate on the stack otherwise because it's so much more convenient.

Note that in the second rule, by "large object" I mean something like

char buffer[1024 * 1024];  // 1MB buffer

but not

std::vector<char> buffer(1024 * 1024);

since the second is actually a very small object wrapping a pointer to a heap-allocated buffer.

As for pointer vs. value members:

• use a pointer if you need heap allocation,
• use a pointer if you're sharing structure,
• use a pointer or reference for polymorphism,
• use a reference if you get an object from client code and the client promises to keep it alive,
• use a value in most other cases.

The use of smart pointers is of course recommended where appropriate. Note that you can use a reference in case of heap allocation because you can always delete &ref, but I wouldn't recommend doing that. References are pointers in disguise with only one difference (a reference can't be null), but they also signal a different intent.

C++ stack vs heap allocation

Use automatic (stack) allocation whenever the function scope - or the scope of a control block such as a for, while, if etc. inside the function - is a good match for the lifetime the object needs. That way, if the object owns/controls any resources, such as dynamically allocated memory, file handles etc. - they will be freed during the destructor call as that scope is left. (Not at some unpredictable later time when a garbage collector winds up).

Only use new if there's a clear need, such as:

• needing the object to live longer than the function scope,

• to hand over ownership to some other code

• to have a container of pointers to base classes that you can then process polymorphically (i.e. using virtual dispatch to derived-class function implementations), or

• an especially large allocation that would eat up much of the stack (your OS/process will have "negotiated" a limit, usually in the 1-8+ megabyte range)

  • if this is the only reason you're using dynamic allocation, and you do want the lifetime of the object tied to a scope in your function, you should use a local std::unique_ptr<> to manage the dynamic memory, and ensure it is released no matter how you leave the scope: by return, throw, break etc.. (You may also use a std::unique_ptr<> data member in a class/struct to manage any memory the object owns.)

Mathieu Van Nevel comments below about C++11 move semantics - the relevance is that if you have a small management object on the stack that controls a large amount of dynamically allocated (heap) memory, move semantics grant extra assurances and fine-grained control of when the management object hands over its resources to another management object owned by other code (often the caller, but potentially some other container/register of objects). This handover can avoid data on the heap being copied/duplicated even momentarily. Additionally, elision and return-value-optimisation often allow nominally automatic/stack-hosted variables to be constructed directly in some memory they're eventually being assigned/returned-to, rather than copied there later.

Which is faster: Stack allocation or Heap allocation

Stack allocation is much faster since all it really does is move the stack pointer.
Using memory pools, you can get comparable performance out of heap allocation, but that comes with a slight added complexity and its own headaches.

Also, stack vs. heap is not only a performance consideration; it also tells you a lot about the expected lifetime of objects.

What and where are the stack and heap?

The stack is the memory set aside as scratch space for a thread of execution. When a function is called, a block is reserved on the top of the stack for local variables and some bookkeeping data. When that function returns, the block becomes unused and can be used the next time a function is called. The stack is always reserved in a LIFO (last in first out) order; the most recently reserved block is always the next block to be freed. This makes it really simple to keep track of the stack; freeing a block from the stack is nothing more than adjusting one pointer.

The heap is memory set aside for dynamic allocation. Unlike the stack, there's no enforced pattern to the allocation and deallocation of blocks from the heap; you can allocate a block at any time and free it at any time. This makes it much more complex to keep track of which parts of the heap are allocated or free at any given time; there are many custom heap allocators available to tune heap performance for different usage patterns.

Each thread gets a stack, while there's typically only one heap for the application (although it isn't uncommon to have multiple heaps for different types of allocation).

To answer your questions directly:

To what extent are they controlled by the OS or language runtime?

The OS allocates the stack for each system-level thread when the thread is created. Typically the OS is called by the language runtime to allocate the heap for the application.

What is their scope?

The stack is attached to a thread, so when the thread exits the stack is reclaimed. The heap is typically allocated at application startup by the runtime, and is reclaimed when the application (technically process) exits.

What determines the size of each of them?

The size of the stack is set when a thread is created. The size of the heap is set on application startup, but can grow as space is needed (the allocator requests more memory from the operating system).

What makes one faster?

The stack is faster because the access pattern makes it trivial to allocate and deallocate memory from it (a pointer/integer is simply incremented or decremented), while the heap has much more complex bookkeeping involved in an allocation or deallocation. Also, each byte in the stack tends to be reused very frequently which means it tends to be mapped to the processor's cache, making it very fast. Another performance hit for the heap is that the heap, being mostly a global resource, typically has to be multi-threading safe, i.e. each allocation and deallocation needs to be - typically - synchronized with "all" other heap accesses in the program.

A clear demonstration:


_{Image source: vikashazrati.wordpress.com}

memory allocation in Stack and Heap

I'm not entirely sure what you're asking, but I'll try my best to answer.

The following declares a variable i on the stack:

int i;

When I ask for an address using &i I get the actual location on the stack.

When I allocate something dynamically using malloc, there are actually TWO pieces of data being stored. The dynamic memory is allocated on the heap, and the pointer itself is allocated on the stack. So in this code:

int* j = malloc(sizeof(int));

This is allocating space on the heap for an integer. It's also allocating space on the stack for a pointer (j). The variable j's value is set to the address returned by malloc.

Determining size at which to switch from stack to heap allocation for multidimensional arrays

A std::vector has a constant size and allocates the actual data always on the heap. So no matter what matrix size you have the Matrix class will be constant size and always store data on the heap.

If you want a heap-free version then you would have to implement a Matrix with std::array. You could use if constexpr to choose between vector and array.

Note that heap allocation cost some time. But they also allow move semantic. The "break even" point might be as little as 4x4 matrixes but you have to test that. new/delete isn't that expensive if it can reuse memory and doesn't have to ask the kernel for more.

Oh, and there is also the option of using a custom allocator for the vector.

The difference between allocating an object on stack and on heap

Garbage Collector is indeed an important factor when the discussion involves unmanaged code, since stack allocation (with stackalloc) would demand less from it. Note that, in heap's case, an array deallocation would be required from garbage collector. On the other hand, for managed code, the allocation is made by default (you can't choose how) - reference types are allocated in the heap, while value types in stack.

Heap vs Stack allocation

I'll start from the beginning...

Vector** v = new Vector*[100];

Allocates an array of 100 pointers to objects of type Vector on the heap
It returns one pointer- v - the you can use to keep track of this array of pointers.

Delete this array of 100 points with:

delete[] v;

(Use the delete operator- delete for a single allocated object, delete[] for an array)

Next case (I'm assuming you mean new Vector[100]:

Vector* v = new Vector[100];

You allocated an array of 100 Vectors on the heap and got a pointer to its start location- v.
Delete this array with:

delete[] v;

Next...

class Vector
{
  int x, y, z;
}

Vector* v = new Vector();

This allocates an object of class Vector on the heap and gives you a pointer to keep track of it. Because you allocated the entire object on the heap, x, y, and z are all allocated on the heap.

Delete it with:

delete v;

class Vector2
{
   int items[10];
}

Vector2* v2 = new Vector2();

This one is a bit trickier but I'm going to reason it out...

Classes are blueprints. You haven't allocated any memory at all until you instantiate the class somehow, in this case on the heap. Because the class is a blueprint, items could not have been allocated until you created an object of class Vector2 on the heap. I think we can reasonably infer that items is thus allocated on the heap.

Delete v2 with:

delete v2;

And finally:

class Vector3
{
   int* items;
}

Vector3 v3 = Vector3();

You allocated all of class Vector3 on the stack, the pointer inside of it items is also allocated thus. Nothing went on the heap, so don't delete it.

C++ at which point does it make sense to use the heap instead of the stack?

On a Windows platform the default stack limit is ~1 megabyte, that means you should definitely put bigger objects on the heap instead of changing the default values (or worse doing it anyway and hope for the best). Check your environment stack size limit before experimenting with it. Also: if your algorithm is a recursive one bear in mind that your stack limit will also put under pressure. Thus also pay attention to your algorithm.

One important point to bear in mind is that stack objects will be destroyed at the end of the function call while heap ones (unless you're using smart pointers - which is recommended) will not. You should plan your choice accordingly. As a rule of thumb big long-time-spanning objects should go on the heap, with some exceptions.

For most applications the performance differences are kinda negligible too. Don't even think of structuring your whole program because of the small performance gain with stack allocations, premature optimization is the root of all evils. Furthermore huge slowdowns usually come from excessive copying stuff around (or allocating too many times small objects), not really from stack/heap choices of allocation.

---

Related Topics