而Chrome则认为99999和100000有天壤之别
Chrome thinks 99,999 is drastically different than 100,000
我刚刚遇到了一个非常有趣的问题，有人发布了一个jsperf基准测试，它与我之前运行的一个几乎相同的基准测试相冲突。
Chrome在这两行之间做了一些完全不同的事情:
new Array(99999); // jsperf ~50,000 ops/sec
new Array(100000); // jsperf ~1,700,000 ops/sec
基准:http://jsperf.com/newarrayassign/2
我想知道是否有人知道这里发生了什么事!
(澄清一下，我正在寻找V8内部的一些低级细节，比如它使用不同的数据结构，这些结构是什么)
只是因为这听起来很有趣，我在V8代码库中搜索了一个定义为100000的静态变量，我找到了这个kInitialMaxFastElementArray var，这是随后在内置ArrayConstructInitializeElements函数中使用的函数。虽然我不是c程序员，不知道这里的细节，但您可以看到它使用if循环来确定它是否小于100,000，并基于此在不同的点执行return。
当你设计适应数据大小的算法时，总是有一些阈值(例如，当你向列表中添加1000个项目时，SharePoint会改变它的工作方式)。因此，猜测您已经找到了实际数字和性能的差异，因为使用了不同的数据结构或算法。
我不知道你使用的是什么操作系统，但如果这是Linux，我怀疑Chrome(即malloc)是从程序管理的堆分配内存(使用sbrk系统调用确定大小，空闲列表由C标准库管理)，但是当你达到一定的大小阈值时，它切换到使用mmap要求内核分配大块内存，不干扰sbrk管理的堆。
Doug Lea描述了malloc在GNU C库中的工作原理，比我做得更好。是他写的
或者100000达到了所需空间量的某种神奇阈值，在尝试分配内存时，它会更频繁地触发垃圾收集器。
