如题，做了一个 C 语言小实验，我分别进行了两个操作，
其一是在堆上申请一个长度为一亿的向量，用来储存 double 类型的数据（包含初始化，全部为 0 ）
其二是在一个一万次的循环里重复创建长度为一万的数组，类型同样为 double，同样初始化为 0
理论上两者都涉及到 cpu 在内存上填入一亿个 0，但后者的速度比前者要快 30 多倍。这让我想到一个问题，就是传统都认为堆比较慢，而慢产生的原因是什么，堆和栈都是普通内存，理论上应并无硬件层面的区别。难道程序申请堆内存都必须要经过操作系统才导致速度变慢吗？但是感觉又跟传统经验不符，毕竟经过操作系统是一个非常昂贵的操作，总不可能程序内部所有动态特性都要经过操作系统吧。
不过不经过操作系统的话，又为什么会慢这么多呢？
确认是一万个独立的数组吗？听起来有可能循环每次结束，数组都被释放了，所以你实际是反复写了同一个数组一万次。那么缓存等等差距就很显然了。
然后了解一下在栈中申请内存的过程 https://stackoverflow.com/a/8629324/1968839
然后了解一下 malloc 是怎么工作的
https://stackoverflow.com/a/3479496/1968839
第二点是进程向操作空间申请内存空间时，一般是先虚拟内存给安排上，访问的时候发现没有对应的物理地址，触发 pagefault，然后才给虚拟地址安排上对应的物理地址。一个页一般是 4KB 。
不确定对不对，仅供参考
在堆上面有一大堆乱七八糟的操作，而且申请堆要走系统调用的
分配机制不一样，栈上肯定不能申请这么大的内存量，栈大小很小的，否则你总听说过 stack overflow 这个词
个人经验，影响内存速度有三点。
1 。 寻址空间大小，我有一个程序，相同的代码，访问 256M 之内时超快，访问 4G 空间时，速度下降一半。
2 。内存对齐，x86 访问非对齐内存，会有额外多余开销。
3 。就是 malloc(堆)和 alloca(栈)区别了，后者是真的快，用飞速也不为过。
malloc 执行过程中是有可能会进入到内核态的，并且，我记得在 Linux 中，给用户进程分配出的虚拟地址事实上并没有对应物理内存，物理地址会在目标 page 第一次被访问时分配。这个可能会造成进程在写入大数组时又多次陷入内核态。
可以尝试 malloc 一次，然后多写几次，丢掉第一次写入的测试数据，用剩下的写入延迟算出一个平均值做结果。
另外，这里栈上的写入过程相当于对同一段栈内存写入了 10000 次。如果不是用 memset 来写的话，那有可能前 9999 次全部被优化掉了只剩下了最后一次。这个得看编译器的生成结果才能确定。
数组大小不同，占用的 CPU cache line 数量也不同。一块 CPU 不是只有一个进程在使用，每个进程对内存的每次读写都可能造成某个 cache line 内的原数据被刷出，新数据被读入。那么数据 size 越大，占用的 cache line 越多，其内部分数据被刷出的概率也就越高，相对性能也就会更差一些。
最后，如果机器内存不大的话，访问堆内存时也可能会因为 swap 和刷 dirty page 损失不少性能。
这个问题会因为主使用了何种 C 语言编译器、如何申请的堆内存有千奇百怪的答案。如果主用的 malloc 内部维护一个结构，且优先考虑直接分配刚刚释放的内存，且没有发生优化，是不可能会有这么大的差别的。
“`
double* test2 = (double*)alloca(10000);
for (int y=0;y<10000;y++)
for (int x=0;x<10000;x++)
{
test2[i] = 0;
}
“`
我的堆 /栈测试代码，test1 堆运行完是 0.4s, test2 栈是 0.2s ，很符合自己盲猜结果。哪有主说的 30 倍差距，肯定是有什么 bug 。
本来以为 alloca 分配的地址，更接近运行代码块，就更容易被 cpu cache，速度就更快。也许看 cpu 心情才是最重要的。