Internet Explorer 渲染通过 JavaScript 生成的表的速度很慢
我正在一个带有大桌子的网络应用程序上的页面上工作。在某些情况下,12 列和最多 300 行。我很难让表格在 Internet Explorer 中快速呈现。我在这段测试代码中复制了我的困难:
一些在具有 4GB RAM 的 Intel 四核 Q8200 上使用 IE9 进行基准测试:
50行,12列:432ms
100行,12列:1023ms
200行,12列:2701ms
400行,12列:8107ms
800 行,12 列:24619ms
指数级糟糕。
我设法找到了一些代码,可以在 Internet Explorer 上更快地呈现相同的测试表,但因为我使用 Mustache.js 模板来呈现我的单元格和行(将所有 HTML 标记保留在 JavaScript 之外),所以我没有能够使用这些 DOM 方法:
基准测试结果:
50行,12列:37ms
100行,12列:72ms
200行,12列:146ms
400 行,12 列:324ms
800 行,12 列:566ms
我无法像第二个示例那样逐块构建表,因为使用客户端模板我需要注入 Mustache 返回的 HTML 字符串。如果您开始将 .innerHTML 放在那里,性能会再次下降。
任何人都可以推荐一种方法来以更有效的方式构建符合客户端模板使用的表格吗?
分页是解决此问题的一种方法,但我想解决问题本身。
任何建议非常感谢!
I'm working on a page on a web app with a large table. 12 columns and up to 300 rows in some cases. I'm having difficulty getting the table to render quickly in Internet Explorer. I've replicated my difficulties in this bit of test code:
Some benchmarks with IE9 on an Intel Quad Core Q8200 with 4GB RAM:
50 rows, 12 columns: 432ms
100 rows, 12 columns: 1023ms
200 rows, 12 columns: 2701ms
400 rows, 12 columns: 8107ms
800 rows, 12 columns: 24619ms
Exponentially bad.
I managed to dig up some code that renders the same test table MUCH faster on Internet Explorer, but because I'm using mustache.js templates to render my cells and rows (keeping all HTML markup out of my JavaScript), I'm not able to use these DOM methods:
Benchmark results:
50 rows, 12 columns: 37ms
100 rows, 12 columns: 72ms
200 rows, 12 columns: 146ms
400 rows, 12 columns: 324ms
800 rows, 12 columns: 566ms
I can't construct the table block by block like in the second example, because with client-side templates I need to inject strings of HTML returned by mustache. If you start sticking .innerHTML's in there, the performance tanks again.
Can anyone recommend a way to build a table in a more efficient manner compliant with the use of client-side templates?
Pagination is one way to manage this issue, but I'd like to resolve the problem itself.
Any suggestions much appreciated!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
首先,我建议将字符串的创建与表的实际创建分开,因为它会产生渲染时间方面的开销。接下来,您应该尝试在将其附加到正文之前创建整个表格,以最大程度地减少重绘/回流的数量。最后,我建议在 IE 中加入一个数组,因为该浏览器中的字符串串联会为每个副本重复分配越来越大的内存块。当您使用数组连接时,浏览器仅分配足够的内存来保存整个字符串。
使用这种方法,我在 IE9 中得到以下结果:
我确信我们可以进一步优化它,但这对于最多 300 行(〜30ms)来说应该足够了,这就是你所说的你的目标。它还将其保持在任何 UI 交互的 50 毫秒以下的圣杯基准之下。
First, I would suggest separating out the creation of the strings from the actual creation of the table because it creates overhead in regards to rendering time. Next, you should try to create the whole table before appending it to the body to minimize the amounts of repaints/reflows. Finally, I would suggest joining an array in IE because string concatenation in that browser repeatedly allocates larger and larger memory blocks for each copy. When you use an array join, the browser only allocates enough memory to hold the entire string.
Using this method, I get the following results in IE9:
I'm sure we could optimize it further, but this should be plenty enough for up to 300 rows (~30ms), which is what you said your goal was. It also keeps it under the holy grail benchmark of under ~50ms for any UI interaction.
使用这个:
减少了大约 130 毫秒。即在将表添加到 DOM 之前在内存中构建表。
这是我的基准:
using this:
Shaved off about 130ms. That is building the table in memory before adding it to the DOM.
Here are my benchmarks:
我想说,由于性能原因,模板不适合这里。使用 DOM 操作构建表并首先包含所有行,然后才附加它是有意义的。这有很大的不同。
您也可以尝试像 jqGrid 这样的东西:它处理大量的行,而只有可见的行以 html (虚拟列表)的形式呈现在屏幕上。
I would say that templates are just not suitable here because of performance reasons. And it makes sense to build the table using DOM manipulation with all the rows first, and only then append it. It makes a big difference.
You can try something like jqGrid as well: it handles huge amount of rows while only visible rows are rendered on the screen in html (virtual list).