可能添加大量的DOM节点没有浏览器窒息？ [英] Possible to add large amount of DOM nodes without browser choking?

问题描述

我的网站上显示了一个表格，每隔10秒重新加载XML源数据（使用XmlHttpRequest），然后更新表格，向用户显示数据的任何添加或删除。为此，JavaScript函数首先清除表中的所有元素，然后为每个数据单元添加一个新行。

I have a webpage on my site that displays a table, reloads the XML source data every 10 seconds (with an XmlHttpRequest), and then updates the table to show the user any additions or removals of the data. To do this, the JavaScript function first clears out all elements from the table and then adds a new row for each unit of data.

最近，我通过一些这个DOM破坏和创建代码引起的Internet Explorer中的内存泄漏（大部分与JavaScript对象和DOM对象之间的循环引用有关，而且我们使用的JavaScript库静态地保留对使用 new Element（...）直到页面被卸载）。

Recently, I battled thru a number of memory leaks in Internet Explorer caused by this DOM destroy-and-create code (most of them having to do with circular references between JavaScript objects and DOM objects, and the JavaScript library we are using quietly keeping a reference to every JS object created with new Element(...) until the page is unloaded).

随着内存问题的解决，我们现在发现了基于CPU的问题：当用户有大量的数据要查看（100+个数据，等于100 < tr> 节点创建，加上每列的所有表单元格），进程绑定CPU，直到Internet Explorer提示用户： / p>

With the memory problems solved, we've now uncovered a CPU-based problem: when the user has a large amount of data to view (100+ units of data, which equals 100 <tr> nodes to create, plus all of the table cells for each column), the process ties up the CPU until Internet Explorer prompts the user with:

停止运行此脚本？

此页面上的脚本导致Internet Explorer运行缓慢。
如果它继续运行，您的计算机可能会变得
无响应。

Stop running this script?
A script on this page is causing Internet Explorer to run slowly. If it continues to run, your computer may become unresponsive.

电池创建代码乘以100多个数据是什么导致CPU使用率尖峰，该功能需要太长（从IE的角度）运行，从而导致IE为用户生成此警告。我也注意到，当更新屏幕功能运行100行时，IE不会重新呈现表内容，直到该函数完成（因为JS解释器在该时间段内使用100％的CPU，我认为）

It seems that running the row-and-cell-creation code times 100+ pieces of data is what is causing the CPU usage to spike, the function to take "too long" (from IE's perspective) to run, thus causing IE to generate this warning for the user. I've also noticed that while the "update screen" function runs for the 100 rows, IE does not re-render the table contents until the function completes (since the JS interpreter is using 100% CPU for that time period, I assume).

所以我的问题是：JavaScript有什么办法让浏览器暂停执行JS并重新渲染DOM吗？如果没有，是否有任何处理创建大量DOM节点的策略，而不是浏览器阻塞？

So my question is: Is there any way in JavaScript to tell the browser to pause JS execution and re-render the DOM? If not, are there any strategies for handling creating large amounts of DOM nodes and not having the browser choke?

我可以想到的一种方法是异步处理更新表逻辑;也就是说，一旦重新加载XML数据的Ajax方法完成，将数据放入某种数组，然后设置一个函数（使用 setInterval（））运行它将一次处理数组的一个元素。然而，这似乎有点像在JavaScript环境中重新创建线程，这似乎可能会变得非常复杂（即如果另一个Ajax数据请求在我仍然重新创建表的DOM节点？的时候呢？

One method I can think of would be to handle the "update table" logic asynchronously; that is, once the Ajax method to reload the XML data is complete, put the data into some sort of array, and then set a function (using setInterval()) to run which will handle one element of the array at a time. However this seems a little bit like re-creating threading in a JavaScript environment, which seems like it could get very complicated (i.e. what if another Ajax data request fires while I'm still re-creating the table's DOM nodes?, etc.)

更新：只是想解释为什么我接受RoBurg的答案。在做一些测试时，我发现我的框架中的新的Element（）方法（我正在使用 mootools ）在IE7中的传统 document.createElement（）的速度大约是两倍。我运行测试创建1000 < spans> ，并将它们添加到< div> 中，使用 new Element（）在IE7上运行大约1800ms（在虚拟PC上运行），传统方法大约需要800ms。

update: Just wanted to explain why I'm accepting RoBurg's answer. In doing some testing, I've found that the new Element() method in my framework (I'm using mootools) is about 2x as slow as the traditional document.createElement() in IE7. I ran a test to create 1000 <spans> and add them to a <div>, using new Element() takes about 1800ms on IE7 (running on Virtual PC), the traditional method takes about 800ms.

我的测试也揭示了一个更快的方法，至少对于一个简单的测试，如我的：使用 DocumentFragments如John Resig 使用IE7在同一台机器上运行相同的测试需要247ms，从我原来的方法改进了9x

My test also revealed an even quicker method, at least for a simple test such as mine: using DocumentFragments as described by John Resig. Running the same test on the same machine with IE7 took 247ms, a 9x improvement from my original method!

推荐答案

100 < tr> 是不是真的那么多...你还在使用该框架的新的Element（） code>？这可能是其原因。

100 <tr>'s isn't really that much... are you still using that framework's new Element()? That might be the cause of it.

您应该测试新元素的速度Element（） vs document.createElement（） vs .innerHTML

You should test the speed of new Element() vs document.createElement() vs .innerHTML

还可以尝试构建dom在内存中，然后将其附加到最后的文档。

Also try building the dom tree "in memory" then append it to the document at the end.

最后看到你不看，长度太多，或其他位和bobs像这样。

Finally watch that you're not looking at .length too often, or other bits and bobs like that.

这篇关于可能添加大量的DOM节点没有浏览器窒息？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！