这个问题可能听起来相当简单，但这是我与另一位开发人员的争论。
我小心地在我可以的地方进行堆栈分配，而不是堆分配。他和我说话，看着我的肩膀，并评论说，这是没有必要的，因为他们的表现是一样的。
在我的印象中，增加堆栈是一个常数时间，而堆分配的性能取决于当前堆的复杂性，包括分配(找到合适大小的孔)和反分配(缩小孔以减少碎片，如果我没有弄错的话，许多标准库实现在删除过程中需要时间来做这件事)。
在我看来，这可能非常依赖于编译器。在这个项目中，我特别使用了一个用于PPC架构的Metrowerks编译器。对这种组合的深入了解将是最有帮助的，但一般来说，对于GCC和msvc++，情况如何?堆分配不如堆栈分配高效吗?没有区别吗?还是差异如此之小以至于变成了毫无意义的微观优化。
当前回答
这不仅仅是堆栈分配更快。您还可以在使用堆栈变量方面获得很多好处。它们有更好的参考位置。最后，折价也便宜得多。
其他回答
堆栈的容量有限，而堆则不是。一个进程或线程的典型堆栈大约是8K。一旦分配，就不能更改大小。
堆栈变量遵循作用域规则，而堆变量则不遵循。如果你的指令指针超出了一个函数，所有与该函数相关的新变量都会消失。
最重要的是，您无法预先预测整个函数调用链。因此，仅200字节的分配就可能导致堆栈溢出。如果您正在编写一个库，而不是应用程序，这一点尤其重要。
可能堆分配和堆栈分配的最大问题是，堆分配在一般情况下是一个无界操作，因此在有时间问题的地方不能使用它。
对于时间不是问题的其他应用程序，它可能没有那么重要，但如果您分配了很多堆，这将影响执行速度。总是尝试将堆栈用于短期和经常分配的内存(例如在循环中)，并尽可能长时间地在应用程序启动期间进行堆分配。
我认为生命期很重要，被分配的东西是否必须以复杂的方式构造。例如，在事务驱动的建模中，您通常必须填写并将带有一堆字段的事务结构传递给操作函数。以OSCI SystemC TLM-2.0标准为例。
在栈上靠近操作调用的地方分配这些资源往往会导致巨大的开销，因为这种构造非常昂贵。好的方法是在堆上分配和重用事务对象，或者通过池或简单的策略，如“这个模块只需要一个事务对象”。
这比在每个操作调用上分配对象快很多倍。
原因很简单，该对象具有昂贵的结构和相当长的使用寿命。
我会说:两种都试试，看看哪种最适合你，因为这真的取决于你代码的行为。
通常，堆栈分配只是由堆栈指针寄存器中的减法组成。这比搜索堆快多了。
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.
关于这种优化有一个普遍的观点。
您得到的优化与程序计数器实际在该代码中的时间成正比。
如果您对程序计数器进行采样，您将发现它在哪里花费时间，这通常是在代码的一小部分，并且通常是在您无法控制的库例程中。
只有当你发现在对象的堆分配上花费了大量时间时，才会明显地更快地进行堆栈分配。
