但是为什么浏览器 DOM 经过 10 年的努力仍然如此缓慢? [英] But why's the browser DOM still so slow after 10 years of effort?
问题描述
Web 浏览器 DOM 自 90 年代末就已经存在，但它仍然是性能/速度方面的最大限制之一.
我们有来自 Google、Mozilla、Microsoft、Opera、W3C 和其他各种组织的一些世界上最杰出的人才为我们所有人研究网络技术，所以显然这不是一个简单的哦，我们没有"t 优化它"问题.
我的问题是如果我要在专门处理此问题的网络浏览器部分工作，为什么我会很难让它运行得更快?
我的问题不是问
有趣的是，似乎不同的浏览器在生成 DOM 时都面临着不同的挑战.为什么会出现这样的差距?
当您更改 DOM 中的某些内容时，它可能会产生无数与重新计算布局、样式表等有关的副作用.
这不是唯一的原因:当您设置 element.innerHTML=x 时，您不再处理普通的在此处存储值"变量，而是处理更新负载的特殊对象设置它们时浏览器中的内部状态.
element.innerHTML=x 的全部含义是巨大的.粗略概述:
- 将
x解析为 HTML - 向浏览器扩展请求许可
- 销毁
element的现有子节点 - 创建子节点
- 重新计算根据父子关系定义的样式
- 重新计算页面元素的物理尺寸
- 将更改通知浏览器扩展
- 更新作为真实 DOM 节点句柄的 Javascript 变量
所有这些更新都必须通过一个 API 来连接 Javascript 和 HTML 引擎.如今 Javascript 如此之快的一个原因是我们将其编译为某种更快的语言甚至机器代码，由于值的行为是明确定义的，因此会发生大量优化.当通过 DOM API 工作时，没有是可能的.其他地方的加速已经把 DOM 抛在了后面.
The web browser DOM has been around since the late '90s, but it remains one of the largest constraints in performance/speed.
We have some of the world's most brilliant minds from Google, Mozilla, Microsoft, Opera, W3C, and various other organizations working on web technologies for all of us, so obviously this isn't a simple "Oh, we didn't optimize it" issue.
My question is if i were to work on the the part of a web browser that deals specifically with this, why would I have such a hard time making it run faster?
My question is not asking what makes it slow, it's asking why hasn't it become faster?
This seems to be against the grain of what's going on elsewhere, such as JS engines with performance near that of C++ code.
Example of quick script:
for (var i=0;i<=10000;i++){
someString = "foo";
}
Example of slow because of DOM:
for (var i=0;i<=10000;i++){
element.innerHTML = "foo";
}
Some details as per request:
After bench marking, it looks like it's not an unsolvable slow issue, but often the wrong tool is used, and the tool used depends on what you're doing cross-browser.
It looks like the DOM efficiency varies greatly between browsers, but my original presumption that the dom is slow and unsolvable seems to be wrong.
I ran tests against Chrome, FF4, and IE 5-9, you can see the operations per second in this chart:
Chrome is lightning fast when you use the DOM API, but vastly slower using the .innerHTML operator (by a magnitude 1000-fold slower), however, FF is worse than Chrome in some areas (for instance, the append test is much slower than Chrome), but the InnerHTML test runs much faster than chrome.
IE seems to actually be getting worse at using DOM append and better at innerHTML as you progress through versions since 5.5 (ie, 73ops/sec in IE8 now at 51 ops/sec in IE9).
I have the test page over here:
http://jsperf.com/browser-dom-speed-tests2
What's interesting is that it seems different browsers seem to all be having different challenges when generating the DOM. Why is there such disparity here?
When you change something in the DOM it can have myriad side-effects to do with recalculating layouts, style sheets etc.
This isn't the only reason: when you set element.innerHTML=x you are no longer dealing with ordinary "store a value here" variables, but with special objects which update a load of internal state in the browser when you set them.
The full implications of element.innerHTML=x are enormous. Rough overview:
- parse
xas HTML - ask browser extensions for permission
- destroy existing child nodes of
element - create child nodes
- recompute styles which are defined in terms of parent-child relationships
- recompute physical dimensions of page elements
- notify browser extensions of the change
- update Javascript variables which are handles to real DOM nodes
All these updates have to go through an API which bridges Javascript and the HTML engine. One reason that Javascript is so fast these days is that we compile it to some faster language or even machine code, masses of optimisations happen because the behaviour of the values is well-defined. When working through the DOM API, none of this is possible. Speedups elsewhere have left the DOM behind.
这篇关于但是为什么浏览器 DOM 经过 10 年的努力仍然如此缓慢?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
