What is more efficient stack memory or heap?

Possible duplicate:
C ++ What's faster: stack allocation or heap allocation

What is more efficient in terms of memory allocation - stack memory or heap memory? What does it depend on?

Obviously, the overhead of dynamic allocation compared to the distribution in the stack. Using a heap involves finding a location in which memory can be allocated and a structure is maintained. On the stack, this is simple since you already know where to put the item. I would like to understand what is the worst-case overhead in milliseconds to support structures that allow dynamic allocation?

+6
c ++ compiler-construction memory
source share
4 answers

The stack is usually more efficient in speed and easy to use!

I tend to agree with Michael from the Joel on Software website, which says:

It is more efficient to use the stack if possible.

When you allocate from a heap, the heap manager must go through what is sometimes relatively difficult procedure to find a free piece of memory. Sometimes he has to look around a bit to find something of the right size.

This is usually not a terrible amount of overhead, but it is definitely more complicated work compared to how the function stack. When you use memory from the stack, the compiler is able to immediately require a piece of memory from the stack to use. This is a fundamentally simpler procedure.

However, the stack size is equally limited, so you should not use it for very large things, if you need something more than something like 4k or so, then you should always grab it from the heap instead.

Another advantage of using the stack is that it is automatically cleared when the current function exits, you do not need to worry about clearing it yourself. You have to be a lot more careful with the allocation of the heap to make sure they are cleaned. Using smart pointers that handle automatic deletion of heap allocations can help a lot with this.

I hate it when I see code that does things, how it extracts 2 integers from the heap, because the programmer needs a pointer to 2 integers and when they see the pointer, they just automatically assume that they need to use the heap. I tend to see this with less experienced coders - this is the type of thing you should use the stack and just an array of 2 integers declared on the stack.

A quote from a really good discussion on Joel on Software :

stack versus heap: more efficiency?

+6
source share

Allocating / deallocating on the stack is more “efficient” because it simply involves increasing / decreasing the stack pointer, usually while allocating the heap is usually much more complicated. However, it is generally not good to have huge things on your stack, since the stack space is much more limited than the heap of space on most systems (especially when multiple threads are involved, since each thread has a separate stack).

+4
source share

These two areas of memory are optimized for different use cases.

The stack is optimized for the case when objects are freed in FIFO order, that is, new objects are always allocated in front of old objects. Because of this, memory can be allocated and freed up quickly by simply supporting a gigantic array of bytes, and then giving or pulling out bytes at the end. Since the memory needed to store local variables for function calls is always restored in this way (since the functions always finish executing in the reverse order from which they were called), the stack is a great place to allocate this kind of memory.

However, the stack is not suitable for other types of distribution. You cannot easily free memory allocated from the stack, which is not the most recently allocated block, as this leads to "gaps" in the stack and complicates the logic of determining where bytes are available. For these types of distributions, when the lifetime of an object cannot be determined from the moment the object was allocated, the heap is the best place to store things. There are many ways to implement the heap, but most of them somehow rely on the idea of ​​storing a giant table or a linked list of blocks that are distributed in a way that makes it easy to find suitable chunks of memory for customer feedback. When the memory is freed, it is then added back to the table or linked list, and perhaps some other logic is used to compact the blocks with other blocks. Due to this overhead from the search time, the heap is usually much, much slower than the stack. However, the heap can perform distributions in templates that are usually not suitable for the stack, so they are usually present in the program.

Interestingly, there are other ways of allocating memory that fall somewhere between them. One general allocation method uses something called an “arena,” where one large piece of memory is allocated from the heap, which is then split into smaller blocks, for example, on the stack. This gives the advantage that the distributions from the arena are very fast if the distributions are sequential (for example, if you are going to select many small objects that all live about the same length), but the objects can survive any call to a certain function. and this is just a small sample of what is possible, but should clearly show that memory allocation is associated with trade-offs. You just need to find a dispenser that suits your specific needs.

+1
source share

The stack is much more efficient, but limited in size. I think this is something like 1MByte.

When allocating memory on the heap, I remember the number 1000. Allocating to the heap is about 1000 times slower than on the stack.

0
source share

All Articles