Is data allocated on the heap slower to access than data allocated on the stack?

Question

I've heard conflicting opinions on that matter.

Some say that accessing data allocated on the heap (ie std::vector or dynamic arrays allocated through malloc) is always marginally slower than accessing data allocated on the stack, because the process must always go through an intermediate pointer to access that data, which is likely located on a wholly different area of memory; on the other hand, they maintain, accesing data allocated on the stack doesn't require going through this intermediate pointer and this data is likely already cached.

Others claim that only allocation of data is slower on the heap than on the stack (because of the overhead of malloc, mmap and similar functions), but access is not, except for the rare cases when the stack and the heap are located on different physical drives.

What is the truth?

Answer 1

Some say that accessing data allocated on the heap (ie std::vector or dynamic arrays allocated through malloc) is always marginally slower than accessing data allocated on the stack, because the process must always go through an intermediate pointer to access that data, which is likely located on a wholly different area of memory; on the other hand, they maintain, accesing data allocated on the stack doesn't require going through this intermediate pointer and this data is likely already cached.

This is bovine fecal waste mater. Only static can be accessed without an intermediate pointer register. Stack data is access through a register (SP) with some processors having supplemental stack registers (e.g., BP, AP).

In addition, memory is memory is memory. the only think that makes memory a stack is that it is accessed as a stack.

Others claim that only allocation of data is slower on the heap than on the stack (because of the overhead of malloc, mmap and similar functions), but access is not

This is correct. Allocating data on a stack requires only one instruction.

Answer 2

The truth (at least on most modern cpus) is that both stack and heap perform the same since they are both just pieces of RAM. So dereferencing a pointer is pretty much the same.

The difference is that stack is preallocated for your process/thread, hence you don't need malloc and free syscalls to work with it. Especially malloc is costly. Another difference is that there might be some specific CPU instructions for working with the stack that increase performance (e.g. assembly's push, pop). These however are unlikely to have anything to do with memory access (as in loading memory to registers) per se.

Another difference is that if you run out of the stack your program will (more then likely) crash. While if you run out of the heap then your OS will likely use swap for you reducing the performance thousands of times.

Cache misses is of course a factor and it will more often happen on the heap then on the stack. But this is simply because the heap is very big compared to the stack. But note that cache misses are not really that important unless you are writing extremely cpu heavy code.

Now you are right that std::vector has to dereference additonal time. But what is slow here is dereferencing, not those pointers being on stack or heap. It doesn't matter where they are. Double dereferencing is always slower then single.

Now it is also possible that stack and heap are on different physical devices. And that these two devices have different speeds (potentially with heap being faster). But this is again unrelated to stack and heap per se. This can happen to any two parts of the memory. And you can't really do anything about it. Not even OS can (well, maybe it can, I'm not sure about that). It's motherboard's thing. Also it is very likely that the motherboard will underclock the faster device anyway.