这个问题可能听起来相当简单，但这是我与另一位开发人员的争论。
我小心地在我可以的地方进行堆栈分配，而不是堆分配。他和我说话，看着我的肩膀，并评论说，这是没有必要的，因为他们的表现是一样的。
在我的印象中，增加堆栈是一个常数时间，而堆分配的性能取决于当前堆的复杂性，包括分配(找到合适大小的孔)和反分配(缩小孔以减少碎片，如果我没有弄错的话，许多标准库实现在删除过程中需要时间来做这件事)。
在我看来，这可能非常依赖于编译器。在这个项目中，我特别使用了一个用于PPC架构的Metrowerks编译器。对这种组合的深入了解将是最有帮助的，但一般来说，对于GCC和msvc++，情况如何?堆分配不如堆栈分配高效吗?没有区别吗?还是差异如此之小以至于变成了毫无意义的微观优化。
当前回答
堆栈的容量有限，而堆则不是。一个进程或线程的典型堆栈大约是8K。一旦分配，就不能更改大小。
堆栈变量遵循作用域规则，而堆变量则不遵循。如果你的指令指针超出了一个函数，所有与该函数相关的新变量都会消失。
最重要的是，您无法预先预测整个函数调用链。因此，仅200字节的分配就可能导致堆栈溢出。如果您正在编写一个库，而不是应用程序，这一点尤其重要。
其他回答
前面提到过，堆栈分配只是移动堆栈指针，即大多数架构上的一条指令。将其与堆分配中通常发生的情况进行比较。
操作系统以链表的形式维护部分空闲内存，有效负载数据由指向空闲部分起始地址的指针和空闲部分的大小组成。为了分配X字节的内存，将遍历链表，并按顺序访问每个音符，检查其大小是否至少为X。当找到大小为P >= X的部分时，将P分成大小为X和P-X的两个部分。更新链表并返回指向第一部分的指针。
如您所见，堆分配取决于许多因素，如您请求的内存大小、内存的碎片程度等等。
我不认为堆栈分配和堆分配通常是可以互换的。我也希望它们的性能都足以用于一般用途。
我强烈推荐小件物品，哪种更适合分配范围。对于较大的项，堆可能是必要的。
在有多个线程的32位操作系统上，堆栈通常是相当有限的(尽管通常至少是几mb)，因为需要分割地址空间，迟早一个线程堆栈会碰到另一个线程堆栈。在单线程系统(至少是Linux glibc单线程)上，限制要小得多，因为堆栈可以不断增长。
在64位操作系统上，有足够的地址空间使线程堆栈相当大。
堆栈要快得多。它在大多数架构上只使用一条指令，在大多数情况下，例如在x86上:
sub esp, 0x10
(将堆栈指针向下移动0x10个字节，从而“分配”这些字节供变量使用。)
当然，堆栈的大小是非常非常有限的，因为你很快就会发现你是否过度使用堆栈分配或尝试进行递归:-)
同样，没有什么理由去优化那些不需要它的代码的性能，比如通过分析来证明。“过早的优化”通常会导致比它本身价值更多的问题。
我的经验法则:如果我知道我将在编译时需要一些数据，并且它的大小在几百字节以下，我就会对它进行堆栈分配。否则我进行堆分配。
正如其他人所说，堆栈分配通常要快得多。
但是，如果复制对象的代价很高，那么如果不小心，在堆栈上分配可能会导致以后使用对象时的巨大性能损失。
例如，如果你在堆栈上分配了一些东西，然后将其放入容器中，那么在堆上分配并将指针存储在容器中会更好(例如使用std::shared_ptr<>)。同样的情况也适用于按值传递或返回对象，以及其他类似的情况。
重点是，尽管在许多情况下堆栈分配通常比堆分配更好，但有时如果你在不最适合计算模型的情况下费尽脑汁进行堆栈分配，它可能会导致比它解决的问题更多的问题。
Remark that the considerations are typically not about speed and performance when choosing stack versus heap allocation. The stack acts like a stack, which means it is well suited for pushing blocks and popping them again, last in, first out. Execution of procedures is also stack-like, last procedure entered is first to be exited. In most programming languages, all the variables needed in a procedure will only be visible during the procedure's execution, thus they are pushed upon entering a procedure and popped off the stack upon exit or return.
现在来看一个不能使用堆栈的例子:
Proc P
{
pointer x;
Proc S
{
pointer y;
y = allocate_some_data();
x = y;
}
}
If you allocate some memory in procedure S and put it on the stack and then exit S, the allocated data will be popped off the stack. But the variable x in P also pointed to that data, so x is now pointing to some place underneath the stack pointer (assume stack grows downwards) with an unknown content. The content might still be there if the stack pointer is just moved up without clearing the data beneath it, but if you start allocating new data on the stack, the pointer x might actually point to that new data instead.
