What is more efficient stack memory or heap?
Possible Duplicate:
C++ Which is faster: Stack allocation or Heap allocation
What is more efficient from memory allocation perspective - stack memory or heap memory? What it depends on?
Obviously there is an overhead of dynamic allocation versus allocation on the stack. Using heap involves finding a location where the memory can be allocated and maintaining structures. On the stack it is simple as you already know where to put the element. I would like to understand what is the overhead in worst case in milliseconds on supporting structures that allow for dynamic allocation?
Stack is usually more efficient speed-wise, and simple to implement!
I tend to agree with Michael from Joel on Software site, who says,
It is more efficient to use the stack when it is possible.
When you allocate from the heap, the heap manager has to go through what is sometimes a relatively complex procedure, to find a free chunk of memory. Sometimes it has to look around a little bit to find something of the right size.
This is not normally a terrible amount of overhead, but it is definitely more complex work compared to how the stack functions. When you use memory from the stack, the compiler is able to immediately claim a chunk of memory from the stack to use. It's fundamentally a more simple procedure.
However, the size of the stack is limited, so you shouldn't use it for very large things, if you need something that is greater than something like 4k or so, then you should always grab that from the heap instead.
Another benefit of using the stack is that it is automatically cleaned up when the current function exits, you don't have to worry about cleaning it yourself. You have to be much more careful with heap allocations to make sure that they are cleaned up. Using smart pointers that handle automatically deleting heap allocations can help a lot with this.
I sort of hate it when I see code that does stuff like allocates 2 integers from the heap because the programmer needed a pointer to 2 integers and when they see a pointer they just automatically assume that they need to use the heap. I tend to see this with less experienced coders somewhat - this is the type of thing that you should use the stack for and just have an array of 2 integers declared on the stack.
Quoted from a really good discussion at Joel on Software site:
stack versus heap: more efficiency?
Allocating/freeing on the stack is more "efficient" because it just involves incrementing/decrementing a stack pointer, typically, while heap allocation is generally much more complicated. That said, it's generally not a good idea to have huge things on your stack as stack space is far more limited than heap space on most systems (especially when multiple threads are involved as each thread has a separate stack).
These two regions of memory are optimized for different use cases.
The stack is optimized for the case where objects are deallocated in a FIFO order - that is, newer objects are always allocated before older objects. Because of this, memory can be allocated and deallocated quickly by simply maintaining a giant array of bytes, then handing off or retracting the bytes at the end. Because the the memory needed to store local variables for function calls is always reclaimed in this way (because functions always finish executing in the reverse order from which they were called), the stack is a great place to allocate this sort of memory.
However, the stack is not good at doing other sorts of allocation. You cannot easily deallocate memory allocated off the stack that isn't the most-recently allocated block, since this leads to "gaps" in the stack and complicates the logic for determining where bytes are available. For these sorts of allocations, where object lifetime can't be determined from the time at which the object is allocated, the heap is a better place to store things. There are many ways to implement the heap, but most of them rely somehow on the idea of storing a giant table or linked list of the blocks that are allocated in a way that easily allows for locating suitable chunks of memory to hand back to clients. When memory is freed, it is then added back in to the table or linked list, and possibly some other logic is applied to condense the blocks with other blocks. Because of this overhead from the search time, the heap is usually much, much slower than the stack. However, the heap can do allocations in patterns that the stack normally is not at all good at, hence the two are usually both present in a program.
Interestingly, there are some other ways of allocating memory that fall somewhere in-between the two. One common allocation technique uses something called an "arena," where a single large chunk of memory is allocated from the heap that is then partitioned into smaller blocks, like in the stack. This gives the benefit that allocations from the arena are very fast if allocations are sequential (for example, if you're going to allocate a lot of small objects that all live around the same length), but the objects can outlive any particular function call. Many other approaches exist, and this is just a small sampling of what's possible, but it should make clear that memory allocation is all about tradeoffs. You just need to find an allocator that fits your particular needs.
链接地址: http://www.djcxy.com/p/13876.html上一篇: 什么是动态内存使用较慢？
下一篇: 什么是更高效的堆栈内存或堆？