I have a quite plex javascript produced by GWT and it works great in all browser (including IE10) but in IE11 I'm facing performance issues.

Activating profiler I discovered how the most consuming code is...(in order from the most consuming)

clientWidth,offsetHeight, and similar methods with impressing values:

clientWidth 32 seconds (32806ms) for just 60 calls offsetHeight 29seconds for 181 calls

it seems to me the cause of my performance issues localised in IE11 (consider the execution in IE10 is around 2seconds for the whole code) and beside naturally I can start optimise reducing the number of call (if possible) i would like to understand if there's anything wrong with methods i'm using or something else Anyone knows what's so wrong in IE11?

UPDATE: just to give a term of pare: clientWidth in the same code in document mode=10 it's 15ms... a difference of 2000times so strange i can't find a bug of IE in this, same code, same methods profiled in document mode edge (11) vs 10

UPDATE: going deeper with profiler seems that clientWidth dig inside my tree more time:

I see :clientWidth -> Layout -> html-> body -> table x -> generated parent for display:table -> td -> table-> generated table for display:table -> td -> table.......

and so on for a huge number of time (i can't reach the end of tree!

does anyone know what means generated table for display:table exactly? the only thing i can guess is that IE11 for some reason keep running on the DOM tree more and more to calculate the width... but i can't guess how to break this long cycle

UPDATE with WORKAROUND: Interesting enough (and confirming what saw so far) it exists a way to "solve" the performance issue: set the most external div/container to a fixed size in pixel (at least one of two dimensions) this seams to make easier for IE to calculate the container size and solve every issue. It's an interesting workaround could be useful for some case, unfortunately in my case i would need to keep my "100%" size to adapt different screens...so isn't an acceptable workaround

UPDATE with a possible field limit: Seems the large use of cellWidth and cellHeight is involved, my JS set for almost every div the cell size and the actual size as percentage, removing the cell size seems to reduce the time for size calculation to 1ms for each call!

I have a quite plex javascript produced by GWT and it works great in all browser (including IE10) but in IE11 I'm facing performance issues.

Activating profiler I discovered how the most consuming code is...(in order from the most consuming)

clientWidth,offsetHeight, and similar methods with impressing values:

clientWidth 32 seconds (32806ms) for just 60 calls offsetHeight 29seconds for 181 calls

it seems to me the cause of my performance issues localised in IE11 (consider the execution in IE10 is around 2seconds for the whole code) and beside naturally I can start optimise reducing the number of call (if possible) i would like to understand if there's anything wrong with methods i'm using or something else Anyone knows what's so wrong in IE11?

UPDATE: just to give a term of pare: clientWidth in the same code in document mode=10 it's 15ms... a difference of 2000times so strange i can't find a bug of IE in this, same code, same methods profiled in document mode edge (11) vs 10

UPDATE: going deeper with profiler seems that clientWidth dig inside my tree more time:

I see :clientWidth -> Layout -> html-> body -> table x -> generated parent for display:table -> td -> table-> generated table for display:table -> td -> table.......

and so on for a huge number of time (i can't reach the end of tree!

does anyone know what means generated table for display:table exactly? the only thing i can guess is that IE11 for some reason keep running on the DOM tree more and more to calculate the width... but i can't guess how to break this long cycle

UPDATE with WORKAROUND: Interesting enough (and confirming what saw so far) it exists a way to "solve" the performance issue: set the most external div/container to a fixed size in pixel (at least one of two dimensions) this seams to make easier for IE to calculate the container size and solve every issue. It's an interesting workaround could be useful for some case, unfortunately in my case i would need to keep my "100%" size to adapt different screens...so isn't an acceptable workaround

UPDATE with a possible field limit: Seems the large use of cellWidth and cellHeight is involved, my JS set for almost every div the cell size and the actual size as percentage, removing the cell size seems to reduce the time for size calculation to 1ms for each call!

• javascript
• internet-explorer

• It could be a problem with standard mode vs quirks mode. For some reason, perhaps, your IE11 goes into quirks mode, and that is the reason for the slow performance. Try check what mode the IE11 runs in. – davidkonrad Commented Nov 25, 2014 at 20:11
• nop, checked with javascript:window.alert('You are in ' + (document.patMode==='CSS1Compat'?'Standards':'Quirks') + ' mode.') and the response is Standards Mode...like expected – noone1 Commented Nov 25, 2014 at 20:27
• What about documentMode? msdn.microsoft./en-us/library/ie/cc196988(v=vs.85).aspx and msdn.microsoft./en-us/library/dn321432.aspx – davidkonrad Commented Nov 25, 2014 at 20:31
• 1 BTW: forcing using development tools to act as document mode =10 solve the performance issue...but don't seems a great solution (and I would have to find a way to do it from the page definition to be transparent for users) – noone1 Commented Nov 25, 2014 at 20:43
• 1 Weird. Perhaps you could give an example of the code causing problems? Edit the question and show the code, if it is not too overwhelming. – davidkonrad Commented Nov 25, 2014 at 20:47

1 Answer 1

I can't say I reached a perfect understanding but somehow i solved:

First of all the use of pixel expressed sizes helps but the actual and main problem was i was setting in at least a ponent of GWT cellHeight="150px" and for the same element Height="100%" this traduced in JS and html generated a table with confusing sizes for IE while other browsers were able to manage it. Basically the whole problem is that if there's something not exactly linear the time of calculation for sizes bees huge without raise any warning or error!