使用JS的Internet 11性能

Question

我有一个非常复杂的javascript，由GWT生成，它在所有浏览器(包括IE10)中都工作得很好，但是在IE11中，我面临性能问题。

激活分析器--我发现了最消耗的代码是.(从最消耗的代码中得到的顺序)

clientWidth、offsetHeight和类似的具有印象值的方法：

clientWidth 32秒(32806ms)，只需60个呼叫，offsetHeight 29秒，181个呼叫

在我看来，我的性能问题是在IE11中本地化的(考虑到IE10中的执行对于整个代码大约是2秒)，当然，我可以开始优化，减少调用的次数(如果可能的话)，我想了解我正在使用的方法是否有问题，或者其他人知道IE11中有什么问题吗？

更新:只是为了给出一个术语的比较: clientWidth在相同的代码在mode=10文档中，它是15‘s.一个2000倍的差异如此奇怪，我找不到IE的错误在这个，相同的代码，相同的方法描述在文档模式边缘(11) vs 10。

更新:深入剖析器似乎是clientWidth在我的树中挖掘更多的时间：

我看到:clientWidth ->布局-> html-> body ->表x ->生成的父表用于显示:表-> td ->表->生成的表用于显示:表-> td ->表.

等了很长时间(我到不了树的尽头！)

有没有人知道生成表的确切含义:表？我唯一能猜到的是，由于某种原因，IE11越来越多地运行在DOM树上，以计算宽度……但我猜不出怎么打破这个漫长的循环

解决方法:足够有趣(并确认到目前为止所看到的)它存在一种“解决”性能问题的方法:将最外部的div/容器设置为以像素为单位的固定大小(至少是两个维度中的一个)，这样可以使IE更容易计算容器大小并解决每个问题。这是一种有趣的解决方法，对于某些情况可能是有用的，不幸的是，在我的情况下，我需要保持"100%“的大小来适应不同的screens...so是不可接受的解决办法

使用可能的字段限制进行更新:似乎涉及到cellWidth和cellHeight的大量使用，我的JS设置了几乎每个div的单元大小和实际大小的百分比，删除单元大小似乎可以将计算大小的时间减少到每次调用的1ms！

Answer 1

我不能说我达成了完美的理解，但不知怎么我解决了：

首先，使用像素表示的大小是有帮助的，但实际和主要的问题是，我至少设置了GWT cellHeight=的一个组件“150 it”，对于相同的元素，Height="100%“--这在JS和html中--生成了一个IE大小混乱的表，而其他浏览器能够管理它。基本上，整个问题是，如果有什么东西不完全线性，计算时间的大小变得很大，没有引起任何警告或错误！