这个问题可能听起来相当简单，但这是我与另一位开发人员的争论。
我小心地在我可以的地方进行堆栈分配，而不是堆分配。他和我说话，看着我的肩膀，并评论说，这是没有必要的，因为他们的表现是一样的。
在我的印象中，增加堆栈是一个常数时间，而堆分配的性能取决于当前堆的复杂性，包括分配(找到合适大小的孔)和反分配(缩小孔以减少碎片，如果我没有弄错的话，许多标准库实现在删除过程中需要时间来做这件事)。
在我看来，这可能非常依赖于编译器。在这个项目中，我特别使用了一个用于PPC架构的Metrowerks编译器。对这种组合的深入了解将是最有帮助的，但一般来说，对于GCC和msvc++，情况如何?堆分配不如堆栈分配高效吗?没有区别吗?还是差异如此之小以至于变成了毫无意义的微观优化。
当前回答
我想说的是，实际上GCC生成的代码(我还记得VS)不需要做堆栈分配的开销。
对以下函数表示:
int f(int i)
{
if (i > 0)
{
int array[1000];
}
}
下面是生成的代码:
__Z1fi:
Leh_func_begin1:
pushq %rbp
Ltmp0:
movq %rsp, %rbp
Ltmp1:
subq $**3880**, %rsp <--- here we have the array allocated, even the if doesn't excited.
Ltmp2:
movl %edi, -4(%rbp)
movl -8(%rbp), %eax
addq $3880, %rsp
popq %rbp
ret
Leh_func_end1:
所以无论你有多少局部变量(甚至在if或switch内部)，只有3880会改变为另一个值。除非你没有局部变量，否则这条指令只需要执行。所以分配局部变量没有开销。
其他回答
堆栈要快得多。它在大多数架构上只使用一条指令，在大多数情况下，例如在x86上:
sub esp, 0x10
(将堆栈指针向下移动0x10个字节，从而“分配”这些字节供变量使用。)
当然，堆栈的大小是非常非常有限的，因为你很快就会发现你是否过度使用堆栈分配或尝试进行递归:-)
同样，没有什么理由去优化那些不需要它的代码的性能，比如通过分析来证明。“过早的优化”通常会导致比它本身价值更多的问题。
我的经验法则:如果我知道我将在编译时需要一些数据，并且它的大小在几百字节以下，我就会对它进行堆栈分配。否则我进行堆分配。
可能堆分配和堆栈分配的最大问题是，堆分配在一般情况下是一个无界操作，因此在有时间问题的地方不能使用它。
对于时间不是问题的其他应用程序，它可能没有那么重要，但如果您分配了很多堆，这将影响执行速度。总是尝试将堆栈用于短期和经常分配的内存(例如在循环中)，并尽可能长时间地在应用程序启动期间进行堆分配。
通常，堆栈分配只是由堆栈指针寄存器中的减法组成。这比搜索堆快多了。
Sometimes stack allocation requires adding a page(s) of virtual memory. Adding a new page of zeroed memory doesn't require reading a page from disk, so usually this is still going to be tons faster than searching a heap (especially if part of the heap was paged out too). In a rare situation, and you could construct such an example, enough space just happens to be available in part of the heap which is already in RAM, but allocating a new page for the stack has to wait for some other page to get written out to disk. In that rare situation, the heap is faster.
尽管堆分配器可以简单地使用基于堆栈的分配技术，但堆栈分配几乎总是与堆分配一样快或更快。
However, there are larger issues when dealing with the overall performance of stack vs. heap based allocation (or in slightly better terms, local vs. external allocation). Usually, heap (external) allocation is slow because it is dealing with many different kinds of allocations and allocation patterns. Reducing the scope of the allocator you are using (making it local to the algorithm/code) will tend to increase performance without any major changes. Adding better structure to your allocation patterns, for example, forcing a LIFO ordering on allocation and deallocation pairs can also improve your allocator's performance by using the allocator in a simpler and more structured way. Or, you can use or write an allocator tuned for your particular allocation pattern; most programs allocate a few discrete sizes frequently, so a heap that is based on a lookaside buffer of a few fixed (preferably known) sizes will perform extremely well. Windows uses its low-fragmentation-heap for this very reason.
另一方面，如果线程太多，在32位内存范围上基于堆栈的分配也充满了危险。堆栈需要一个连续的内存范围，因此线程越多，就需要更多的虚拟地址空间来让它们在没有堆栈溢出的情况下运行。对于64位的程序来说，这(目前)不是问题，但是对于具有大量线程的长时间运行的程序来说，它肯定会造成严重破坏。由于碎片化而导致虚拟地址空间耗尽总是一件令人痛苦的事情。
我不认为堆栈分配和堆分配通常是可以互换的。我也希望它们的性能都足以用于一般用途。
我强烈推荐小件物品，哪种更适合分配范围。对于较大的项，堆可能是必要的。
在有多个线程的32位操作系统上，堆栈通常是相当有限的(尽管通常至少是几mb)，因为需要分割地址空间，迟早一个线程堆栈会碰到另一个线程堆栈。在单线程系统(至少是Linux glibc单线程)上，限制要小得多，因为堆栈可以不断增长。
在64位操作系统上，有足够的地址空间使线程堆栈相当大。
