堆和栈数据访问性能对比
众所周知的常识是，对于大多数算法来说，在堆栈上分配和释放数据比在堆上分配和释放数据要快得多。在C++中，代码之间的差异就像
double foo[n*n]
vs。
double* foo = new int[n*n]
但是，当涉及到访问和计算位于堆或堆栈上的数据时，有什么显着差异吗？即，代码应该在几种不同的体系结构上运行，是否存在速度差异
foo[i]
，因此尝试和测量将不起作用。
It is widely known common sense, that for most algorithms, allocating and deallocating data on the stack is much faster than doing so on the heap. In C++, the difference in the code is like
double foo[n*n]
vs.
double* foo = new int[n*n]
But there are any significant differences, when it comes to accessing and calculating with data that lie either on the heap or on the stack? I.e. is there a speed difference for
foo[i]
The code is ought to run on several different architectures, therefore try and measure will not work.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
除了分配之外，无论是基于堆栈还是基于堆，访问数据之间都不应该有明显的区别——归根结底都是内存。
Barring allocation, there should be no discernable difference between accessing data whether it be stack- or heap- based - it's all memory at the end of the day.
可能存在有关缓存局部性和读/写未命中的问题（高度依赖于系统）。如果您在堆栈和堆数据上运行程序，那么可以想象（取决于您的缓存架构），与完全在一个连续区域上运行程序相比，您会遇到更多的缓存未命中。堆栈。这是 Andrew Appel（来自 SML/NJ）和 Zhuhong Shao 撰写的针对此问题的论文，他们在其中研究了这个问题，因为堆栈/堆分配是函数式语言实现的一个主题：
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.3778
他们发现了一些与写入未命中有关的性能问题，但估计这些问题可以通过缓存的进步来解决。
因此，我对当代桌面/服务器计算机的猜测是，除非您正在运行经过高度优化的、架构特定的代码（沿着缓存线传输数据），否则您不会注意到堆栈和堆访问之间的任何差异。对于具有小型缓存的设备（例如 ARM/MIPS 控制器），情况可能会有所不同，忽略缓存无论如何都会对性能产生明显的影响。
There might be (highly system depending) issues about cache locality and read/write misses. If you run your program on the stack and heap data, then it is conceivable (depending on your cache architecture) that you to run into more cache misses, than if you run it entirely on one continuos region of the stack. Here is the paper to this issue by Andrew Appel (from SML/NJ) and Zhong Shao where they investigate exactly this thing, because stack/heap allocation is a topic for the implementation of functional languages:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.3778
They found some performance problems with write misses but estimated these would be resolved by advances in caching.
So my guess for a contemporary desktop/server machine is that, unless you're running heavily optimized, architecture specific code which streams data along the cache lines, you won't notice any difference between stack and heap accesses. Things might be different for devices with small caches (like ARM/MIPS controller), where ignoring the cache can have noticeable performance effects anyway.
作为单个陈述，这并不重要。
如果没有更多背景，就无话可说。有一些有利于堆栈的影响实际上一直可以忽略不计。
堆栈可能已经在缓存中，新分配的堆块可能不在缓存中。然而，这只是第一次执行处罚。对于大量数据，无论如何你都会破坏缓存
堆栈分配本身比堆分配便宜一点，因为分配更简单
从长远来看，堆的主要问题通常是碎片，这是一种（通常）不能归因于单次分配的“累积成本”，但可能会显着增加进一步分配的成本
。衡量这些影响至少是很棘手的。
建议：性能并不是这里的决定因素。可移植性和可扩展性建议对除极少量数据外的所有数据使用堆。
Taken as single statements, it doesn't matter.
Little can be said without more context. There are a few effects in favor of the stack which are negligible virtually all of the time.
the stack is likely in the cache already, a freshly allocated heap block likely is not. However, this is a first execution penalty only. For significant amounts of data, you'd thrash the cache anyway
Stack allocation itself is a bit cheaper than heap allocation, because the allocation is simpler
Long term, the main problem of a heap is usually fragmentation, an "accumulated cost" that (usually) cannot be attributed to single allocations, but may significantly increase the cost of further allocations
Measuring these effects is tricky at least.
Recommendation: performance is not the decider here. Portability and Scalability recommend using the heap for all but very small amount of data.
堆栈将更频繁地位于CPU 缓存中，因此在某些（大多数？）情况下可能会更快。
但最准确的答案可能是：这取决于......
The stack will be in the CPU cache more often, so that might be faster in some (most?) cases.
But the most precise answer is probably: it depends...