javascript - 但为什么浏览器 DOM 经过 10 年的努力仍然如此缓慢？

Question

Web 浏览器 DOM 自上世纪 90 年代后期就已问世，但它仍然是性能/速度方面的最大限制因素之一。

我们拥有来自 Google、Mozilla、Microsoft、Opera、W3C 和各种其他组织的一些世界上最聪明的头脑，他们致力于为我们所有人开发网络技术，所以显然这不是简单的“哦，我们没有”优化它”的问题。

我的问题是如果我在专门处理这个问题的网络浏览器上工作，为什么我会这么困难地让它运行得更快？

我的问题不是问 what 让它变慢，它要求 why 不是变快了吗？

这似乎与其他地方正在发生的事情背道而驰，例如性能接近 C++ 代码的 JS 引擎。

快速脚本示例:

for (var i=0;i<=10000;i++){
    someString = "foo";
}

由于 DOM 而变慢的示例:

for (var i=0;i<=10000;i++){
    element.innerHTML = "foo";
}

---

根据要求的一些细节:

经过bench marking，看起来不是无法解决的慢问题，而是经常用错工具，用什么工具取决于你在跨浏览器做什么。

看起来不同浏览器的 DOM 效率差异很大，但我最初认为 dom 缓慢且无法解决的假设似乎是错误的。

我针对 Chrome、FF4 和 IE 5-9 进行了测试，您可以在这张图表中看到每秒的操作数:

当您使用 DOM API 时，Chrome 快如闪电，但使用 .innerHTML 运算符时要慢得多(慢 1000 倍)，然而，FF 在某些方面比 Chrome 差(例如，追加测试是比 Chrome 慢得多)，但 InnerHTML 测试运行速度比 chrome 快得多。

从 5.5 开始，IE 似乎在使用 DOM append 方面越来越差，而在 innerHTML 方面越来越好(即，IE8 中的 73ops/sec 现在在 IE9 中为 51ops/sec)。

我这里有测试页:

http://jsperf.com/browser-dom-speed-tests2

有趣的是，似乎不同的浏览器在生成 DOM 时似乎都遇到了不同的挑战。为什么会有这样的差距？

Answer 1

当您更改 DOM 中的某些内容时，它可能会产生无数副作用，包括重新计算布局、样式表等。

这不是唯一的原因:当您设置 element.innerHTML=x 时，您不再处理普通的“在此处存储一个值”变量，而是处理更新负载的特殊对象设置它们时浏览器中的内部状态。

element.innerHTML=x 的全部含义是巨大的。粗略概述:

• 将 x 解析为 HTML
• 请求浏览器扩展程序的许可
• 销毁元素的现有子节点
• 创建子节点
• 重新计算根据父子关系定义的样式
• 重新计算页面元素的物理尺寸
• 将更改通知浏览器扩展
• 更新作为真实 DOM 节点句柄的 Javascript 变量

所有这些更新都必须通过连接 Javascript 和 HTML 引擎的 API。现在 Javascript 如此之快的一个原因是我们将它编译成一些更快的语言甚至机器代码，大量的优化发生是因为值的行为是明确定义的。当通过 DOM API 工作时，这都是不可能的。其他地方的加速已经将 DOM 抛在了后面。