为何用迭代器直接访问数组实现杨辉三角比复制向量的方式占用更多内存且速度更慢？

我来帮你拆解这个问题——你用两种方式实现杨辉三角，结果发现用迭代器直接访问的版本反而更慢、占内存更多，确实有点反直觉对吧？咱们一步步来看背后的原因：

一、速度差异（Runtime：0ms vs 3ms） #

先看核心的性能差异：

1. 缓存友好性与访问效率
   第一个实现里，vector<int> last = tri.back();是把最后一行完整复制到了局部向量last里。虽然是复制操作，但复制后的last是一块连续的内存，后续访问last[j]和last[j-1]是直接的数组下标访问——这是CPU最友好的内存访问模式：连续、可预测，缓存命中率极高，几乎没有额外开销。

   第二个实现里，你用auto last = (tri.end()-1)->begin();拿到迭代器，然后通过*(last)+*(++last)来取值。这里有两个隐性开销：

   • 迭代器的解引用（*last）和移动（++last）需要额外的指令，相比直接的数组下标访问，指令数更多；
   • 你每次访问的是原tri容器里的最后一行元素，而tri中的每个行向量是动态分配的内存块（虽然也是连续的），但编译器对这种跨容器的迭代器访问，很难像局部向量那样做极致优化——比如没法把访问逻辑直接映射到寄存器操作，反而要处理迭代器的类型校验、内存地址计算等额外步骤。

2. 编译器优化的差异
   Leetcode的0ms其实是表示运行时间极短，已经快到计时精度的下限了。第一个版本的复制操作，编译器很可能会优化成内存块的快速拷贝（比如用memcpy），甚至因为last是局部变量，后续的下标访问能被直接 inline 到循环里，几乎没有额外开销。而第二个版本的迭代器操作逻辑相对复杂，尤其是*(last)+*(++last)这种带有顺序依赖的操作，编译器很难做等价优化，只能老老实实执行每一步迭代器移动和解引用，自然就慢了。

二、内存差异（Memory：9.54MB vs 9.61MB） #

你觉得第二个版本没有复制向量，应该内存更少，但实际统计结果相反，主要有这几个原因：

1. 统计维度的问题
   Leetcode的内存统计是整个进程的峰值内存占用，不是只看你显式分配的容器大小。第一个版本里的last是局部向量，虽然复制了内存，但它是栈上的局部变量（或者小对象优化后的内存），循环结束后会被立即回收，不会积累内存占用。而第二个版本里，虽然没有显式复制，但：

   • 迭代器的操作会生成一些临时变量（比如存储加法结果的临时int，迭代器移动时的中间状态）；
   • 因为缓存命中率低，CPU的L1/L2缓存会加载更多的内存页，这些缓存占用也会被算进进程的内存统计里。

2. 编译器优化的隐性开销
   第一个版本的复制操作，编译器可以用非常高效的内存拷贝指令，几乎没有额外的内存浪费；而第二个版本的迭代器访问，编译器可能为了保证迭代器的正确性，生成了一些额外的内存操作（比如边界检查），这些操作带来的隐性内存开销，虽然不大，但在Leetcode的精细统计下就会体现出来。

最后补充：Leetcode统计的参考性 #

要注意，Leetcode的计时和内存统计是多次运行的平均值，会受服务器负载、编译器版本等因素影响，但你看到的趋势是真实的——直接的数组访问+局部向量复制，确实比迭代器跨容器访问更高效、更省内存。

内容来源于stack exchange