我有一个非常复杂的JavaScript代码是由GWT生成的，在所有浏览器（包括IE10）中都能很好地工作，但在IE11中我遇到了性能问题。
通过激活分析器，我发现最耗时的代码是...(按照最耗时的顺序)
clientWidth,offsetHeight以及类似的方法具有令人印象深刻的值:
clientWidth 32秒（32806ms）仅60次调用 offsetHeight 29秒，共181个调用
根据我的经验，我的性能问题在IE11中定位，（考虑到IE10中的执行时间大约为2秒），当然，除了自然情况下我可以开始优化减少调用次数（如果可能的话），我想知道是否有任何方法存在问题或其他东西。 有人知道IE11的问题吗？
更新： 只是给出一个比较的术语：在文档模式= 10中，相同代码中的clientWidth为15毫秒...这是2000倍的差异，我无法找到IE的错误，相同的代码，相同的方法在文档模式edge（11）与10进行了分析
更新： 通过分析器进行更深入的研究，看起来clientWidth在我的树内部挖掘了更多的时间：
我看到：clientWidth->布局-> html-> body-> table x->生成的父级用于显示：table-> td-> table->生成的用于显示：table的表格-> td-> table.......等等一大堆次数（我无法达到树的末端！）
有人知道“生成的用于显示：table”到底是什么意思吗？我唯一能猜测的是IE11由于某种原因继续在DOM树上运行以计算宽度...但我无法猜测如何打破这个长周期
更新了解决方法： 有趣的是（并确认迄今为止所看到的），存在一种“解决”性能问题的方法：将最外部的div /容器设置为像素固定大小（至少两个维度中的一个），这似乎更容易使IE计算容器大小并解决所有问题。
这是一个有趣的解决方法，对某些情况可能有用。但不幸的是，在我的情况下，我需要保持我的“100％”大小以适应不同的屏幕…因此不是可接受的解决方法。更新具有可能的字段限制： 似乎涉及到大量使用cellWidth和cellHeight，我的JS为几乎每个div设置了单元格大小和实际大小作为百分比，删除单元格大小似乎将大小计算时间减少到每次调用1毫秒！