我有一个由GWT生成的相当复杂的javascript，它在所有浏览器(包括IE10)中都很好用，但是在IE11中，我遇到了性能问题。
激活分析器后，我发现了最消耗代码的方式...(从最消耗的顺序开始)
clientWidth，offsetHeight和具有令人印象深刻的值的类似方法:
clientWidth 32秒(32806ms)，仅需60个电话
offsetHeight 29秒，共181个 call
在我看来，造成性能问题的原因仅限于IE11(考虑到整个代码IE10的执行时间约为2秒)，此外我自然可以开始优化以减少调用次数(如果可能)，我想了解是否存在我使用的方法有任何问题或其他问题
有人知道IE11有什么问题吗？
更新:
只是为了给一个比较的术语:在文档模式下相同代码中的clientWidth = 10，它是15ms ...相差2000倍，所以很奇怪，在文档模式下配置的相同代码，相同方法中，我找不到IE的错误边缘(11)vs 10
更新:
深入分析器似乎clientWidth在我的树中挖掘的时间更多:
我看到:clientWidth->布局-> html->正文->表x->为display:table-> td-> table->为display:table-> td-> table生成的表..... ..
等等，持续了很多时间(我无法到达树的尽头!
有谁知道生成display:table的表的确切含义是什么？我唯一能猜到的就是IE11由于某种原因会继续在DOM树上运行以计算宽度...但是我无法猜测如何打破这个漫长的周期
使用替代方法进行更新:
足够有趣(并确认到目前为止所看到的内容)，它存在一种“解决”性能问题的方法:将最外部的div /容器设置为固定的像素大小(至少两个维度之一)，以使IE更加容易计算容器尺寸并解决所有问题。
这是一个有趣的解决方法，在某些情况下可能会有用，不幸的是，在我的情况下，我需要保持“100％”大小以适应不同的屏幕...因此，这不是可接受的解决方法
具有可能的字段限制的UPDATE:
似乎涉及到cellWidth和cellHeight的大量使用，我的JS将几乎每个div的像元大小和实际大小设置为百分比，删除像元大小似乎将每次调用的大小计算时间减少到1ms!
最佳答案
我不能说我已经达到了一个完美的理解，但是我却以某种方式解决了:
首先使用像素表示的大小有帮助，但实际和主要问题是我在GWT的至少一个组件中设置cellHeight =“150px”，对于在JS和html中生成的相同元素Height =“100％” IE大小困惑的表格，而其他浏览器却可以管理它。基本上，整个问题是，如果有些东西不是完全线性的，那么尺寸计算的时间就会变得很大，而不会发出任何警告或错误!