为什么对DOM读/写操作进行微小的重新排序会导致巨大的性能差异 [英] why a tiny reordering of DOM Read/Write operations causes a huge performance difference

问题描述

下面的代码说明了这个问题，改变读/写顺序会导致执行时间有很大差异（使用Chrome，Firefox和IE进行测试）：

the following code illustrate the problem, changing the order of Read/Write causes a big difference in execution time (Tested using Chrome, Firefox and IE) :

// read->write->read->write...
function clearSlow(divs){
    Array.prototype.forEach.call(divs, function(div) {
        contents.push(div.clientWidth);
        div.style.width = "10px";
    });
}
// read->read->...->write->write...
function clearFast(divs){
    Array.prototype.forEach.call(divs, function(div) {
        contents.push(div.clientWidth);
    });
    Array.prototype.forEach.call(divs, function(div) {
        div.style.width = "10px";
    });
}

以下是完整示例的一个JSFiddle http://jsfiddle.net/Dq3KZ/2/ 。

Here's a JSFiddle for the complete example http://jsfiddle.net/Dq3KZ/2/ .

我的结果对于n = 100：

慢版本：〜35ms

快速版本：〜2ms

My results for n=100 :
Slow version : ~35ms
Fast version : ~2ms

n = 1000：

慢版本：〜2000ms

快速版本：〜25ms

for n=1000:
Slow version : ~2000ms
Fast version : ~25ms

我认为这与每种情况下浏览器回流的数量有关。在慢速情况下，每次写入操作都会发生回流。然而，在快速的情况下，回流仅在最终发生一次。但是我不确定，我不明白为什么它的工作方式（操作是独立的）。

I think this is related with the number of browser reflow in each case. In the slow scenario, a reflow happens for each write operation. However, in the fast scenario, the reflow occurs only once at the end. But I'm not sure and I don't understand why it does work that way (when the operations are independent).

编辑：我使用 InnerText 属性而不是 clientWidth 和 Style.Width 在使用Google Chrome时，我也有同样的行为（ http://jsfiddle.net/pindexis/CW2BF/ 7 / ）。但是，当使用 InnerHTML 时，几乎没有区别（ http://jsfiddle.net/pindexis/8E5Yj/ ）。

I used InnerText property instead of clientWidth and Style.Width , I got the same behavior when using Google Chrome (http://jsfiddle.net/pindexis/CW2BF/7/). However, when InnerHTML is used, there's almost no difference (http://jsfiddle.net/pindexis/8E5Yj/).

Edit2：我已经开始讨论有关感兴趣的innerHTML / innerText问题：为什么用innerText替换InnerHTML会导致性能降低15倍

I have opened a discussion about the innerHTML/innerText issue for those interested: why does replacing InnerHTML with innerText causes >15X drop in performance

推荐答案

操作不是独立的。

当需要样式或内容大小更改和位置或维度时，必须进行回流，无论是因为您请求一个维度，或者因为屏幕必须更新（代码完成时）。

A reflow must occur when the style or content sizes changed and positions or dimensions are needed, either because you request a dimension or because the screen must be updated (when your code finishes).

div.clientWidth 是一个隐藏函数调用。当您请求此值时，您实际上请求最新值，因此，随着样式更改，您将触发立即回流。

div.clientWidth is a hidden function call. When you request this value, you request in fact an up to date value and thus, as the style changed, you trigger an immediate reflow.

在快速的情况下，在屏幕重画或请求大小之前，没有理由进行回流。在这种情况下，只需要一个回流。

In the "fast" case, there's no reason to do a reflow until the screen is redrawn or you request a size. Only one reflow is really needed in this case.

这篇关于为什么对DOM读/写操作进行微小的重新排序会导致巨大的性能差异的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！