array.push(element) 与 array[array.length] = element

Tom*_*Tom 5 javascript arrays optimization

我想知道是否有选择的理由

array.push(element)
Run Code Online (Sandbox Code Playgroud)

超过

array[array.length] = element
Run Code Online (Sandbox Code Playgroud)

或相反亦然。

这是一个简单的例子,我有一个数字数组,我想用这些数字乘以 2 来创建一个新数组:

var numbers = [5, 7, 20, 3, 13];

var arr1 = [];
var len = numbers.length;
for(var i = 0; i < len; i++){
    arr1.push(numbers[i] * 2);
}
alert(arr1);

var arr2 = [];
for(var i = 0; i < len; i++){
    arr2[arr2.length] = numbers[i] * 2;
}
alert(arr2);
Run Code Online (Sandbox Code Playgroud)

Jos*_*ers 1

使用当前的 JavaScript 技术,同时使用最少的代码,最快的方法是首先存储最后一个元素,从而分配完整的数组索引集,然后在存储元素时向后计数到 0,从而利用附近的元素内存存储位置并最大限度地减少缓存未命中。

var arr3 = [];
for (var i = len; i>0;){
    i--;
    arr2[i] = numbers[i] * 2;
}
alert(arr2);
Run Code Online (Sandbox Code Playgroud)

请注意,如果在 JavaScript 引擎看来,存储的元素数量“足够大”,则该数组将被创建为“稀疏”数组,并且永远不会转换为常规平面数组。

是的,我可以支持这一点。唯一的问题是 JavaScript 优化器非常积极地丢弃不使用的计算。因此,为了公平地计算结果,必须(暂时)存储所有结果。我认为已经过时但实际上进一步提高了速度的另一项优化是使用 来预初始化数组new Array(*length*)。这是一个老套的伎俩,在一段时间内没有任何作用,但在 JavaScript 引擎极端优化的时代,它似乎再次产生了作用。

<script>
function arrayFwd(set) {
var x = [];
for (var i = 0; i<set.length; i++)
x[x.length] = set[i];
return x;
}

function arrayRev(set) {
var x = new Array(set.length);
for (var i = set.length; i>0;) {
i--;
x[i] = set[i];
}
return x;
}

function arrayPush(set) {
var x = [];
for (var i = 0; i<set.length; i++)
x.push(set[i]);
return x;
}

results = []; /* we'll store the results so that
optimizers don't realize the results are not used
and thus skip the function's work completely */
function timer(f, n) {
return function(x) {
var n1 = new Date(), i = n;
do { results.push(f(x)); } while (i-- > 0); // do something here
return (new Date() - n1)/n;
};
}

set = [];
for (i=0; i<4096; i++)
set[i] = (i)*(i+1)/2;

timers = {
forward: timer(arrayFwd, 500),
backward: timer(arrayRev, 500),
push: timer(arrayPush, 500)
};
for (k in timers) {
document.write(k, ' = ', timers[k](set), ' ms<br />');
}
</script>
Run Code Online (Sandbox Code Playgroud)

歌剧 12.15:

向前 = 0.12 毫秒 向后 = 0.04 毫秒 推动 = 0.09 毫秒

Chrome(最新,v27):

向前 = 0.07 毫秒 向后 = 0.022 毫秒 推动 = 0.064 毫秒

(作为比较,当未存储结果时,Chrome 会生成以下数字:向前 = 0.032 毫秒 向后 = 0.008 毫秒 推送 = 0.022 毫秒

这比向前数组快了几乎四倍,比推送快了几乎三倍。)

IE 10:向前 = 0.028 毫秒 向后 = 0.012 毫秒 推送 = 0.038 毫秒

奇怪的是,Firefox 仍然显示推送速度更快。当使用推送时,Firefox 必须在后台进行一些代码重写,因为就纯粹的、未增强的 JavaScript 性能而言,访问属性和调用函数都比使用数组索引慢。

  • 你能支持这一点吗? (3认同)
  • @Qantas94Heavy 你是对的,今天的工作方式与我上次测试时有所不同。以前,逆向操作总是大赢家。现在看来浏览器仍然像你所说的那样创建稀疏数组,特别是Firefox,它通过推送执行得更快。原则上,向后执行应该是最快的,因为它与初始化整个数组然后存储相邻元素执行相同的操作。但由于 JavaScript 引擎的优化,代码中编写的内容并不是后台实际发生的内容。 (2认同)