У меня довольно сложный javascript, выпущенный GWT, и он отлично работает во всех браузерах (включая IE10), но в IE11 я столкнулся с проблемами производительности.
Активация профилировщика Я обнаружил, как наиболее потребляющий код... (в порядке от самого потребляющего)
clientWidth, offsetHeight и аналогичные методы с впечатляющими значениями:
clientWidth 32 секунды (32806ms) всего за 60 вызовов offsetHeight 29 секунд для 181 вызовов
Мне кажется, что причина моих проблем с производительностью локализована в IE11 (подумайте, что выполнение в IE10 составляет около 2 секунд для всего кода), и, естественно, я могу начать оптимизировать сокращение количества вызовов (если возможно), я хотел бы понять, если что-то не так с методами, которые я использую, или что-то еще Кто-нибудь знает, что неправильно в IE11?
UPDATE: просто чтобы дать термин сравнения: clientWidth в том же коде в режиме документа = 10 он 15 мс... разница в 2000 тактов, что я не могу найти ошибку IE в этом же коде, те же методы, профилированные в режиме документа edge (11) vs 10
UPDATE: более глубокая с профилировщиком кажется, что clientWidth копает внутри моего дерева больше времени:
Я вижу: clientWidth → Layout → html- > body → table x → сгенерированный родительский элемент для отображения: table → td → table- > сгенерированная таблица для отображения: table → td → table......
и т.д. за огромное количество времени (я не могу добраться до конца дерева!
Кто-нибудь знает, что означает сгенерированную таблицу для отображения: таблица точно? единственное, что я могу догадаться, это то, что IE11 по какой-то причине продолжает работать в дереве DOM все больше и больше, чтобы вычислить ширину... но я не могу догадаться, как разбить этот длинный цикл
ОБНОВЛЕНИЕ с ПОСЛЕДНЕЕ ВРЕМЯ: Достаточно интересно (и подтверждая, что увидели до сих пор), существует способ "решить" проблему производительности: установите самый внешний div/container на фиксированный размер в пикселе (по крайней мере, один из двух измерений), этот шов, чтобы упростить IE для расчета размера контейнера и решения каждой проблемы. Это интересное обходное решение может быть полезно для некоторых случаев, к сожалению, в моем случае мне нужно будет поддерживать размер "100%" для адаптации разных экранов... так что это не приемлемое обходное решение
UPDATE с возможным полевым пределом: Кажется, что большое использование cellWidth и cellHeight задействовано, мой JS установлен почти для каждого div размер ячейки и фактический размер в процентах, удаление размера ячейки уменьшает время вычисления размера до 1 мс для каждого вызова!
