Wednesday, January 05, 2011 10:10 AMWhen using a table with a reasonable amount of data - 100 rows by 50 columns - I notice that IE8 performance degrades unacceptably (only in IE8 standards rendering mode). The CPU usage spikes to 100% and the browser becomes very sluggish. Increasing the amount of data in the table amplifies the sluggishness.
This became apparent when applying a background color on hover on a row, but the performance degradation seems to occur with any style change, and unrelated to the hover event handling.
Attached is a very simple test-case with which I can consistently reproduce the problem.
A couple of notes concerning the issue:
- Dynatrace reports show that nearly 100% of the CPU time is spent on "Calculating Generic Layout". This does not occur if <div>s are used instead of tables (see below).
- Switching the Document Mode to IE7 Standards or Quirks Mode via the Dev Toolbar fixes the problem.
- Due to constraints imposed on the environment I work in, IE8 runs in IE8 Compat Mode Browser Mode, with IE8 Standards Document Mode. Changing this setting through the Dev Toolbar doesn't have any effect on performance.
- Replacing the <table> solution with <div> / <span> approach improves performance, ruling out the amount of DOM nodes in itself as the culprit.
- The example adds mouseover events to each <tr>, but using event delegation doesn't mitigate the problem. In fact, if I replace the mouseover solution with a setInterval where every 50ms a random row is highlighted, the same performance degradation occurs.
- I have tested and confirmed this behavior on several different machines (all Windows XP, Intel Core Duo @ 2.33 Ghz, with 3.5 GB RAM) in my work environment. All exhibit the same behavior.
- I have tested HTML 4 Strict, XHTML 1.0 strict and HTML5 doctypes. All exhibit the same behavior.
- Pre-rendering the table server-side has no effect on run-time performance.
I believe I have exhausted my options for improving the mouseover effect from a coding perspective, and have to conclude that IE8 <table> handling is extremely poor - although if it is always this bad I am suprised I haven't found more information regarding this subject.
I hope someone else can confirm this behavior in a separate IE8 environment, or point out a mistake on my part.
Thanks in advance.
Wednesday, January 05, 2011 8:21 PM
Use a transition DTD and sepecify width style rules and an width attribute for the <table>...
IE is recalculating cell offsets.
You can submit feedback for IE8 and 9 Beta issues at connect.microsoft.com/ie
You are using computed markup, so your test page will have no errors at the w3c validator.... Install the Tidy HTML validator extension in Firefox and retest your page to detect potential markup errors in your scripted markup. OR In IE9 Beta view the Script tab of the Developer tool to view the computed source... copy and paste the computed source to the w3c validation service.
Friday, January 07, 2011 2:47 PM
Rob, thanks for your suggestions.
I have had implemented these suggestions earlier, unfortunately without any success. Do you have any idea why IE8 performs this much worse than IE7/IE6?
I will submit feedback via connect.
Thanks for your input.
Friday, January 07, 2011 9:17 PM
My gues is that without a table width attribute or style rule, IE browsers are recalculating the cell offsets instead of using first differences. IE6 has rounding errors in its floating point calcs, IE7 uses hasLayout, all versions use line-height to calculate cell heights which probably defaults to ex units, not px, creating rounding errors in the unit conversions.
You may get better interoperability by
1. specifying a table width
2. adding a to the innerHTML of your <td> elements (I think some versions of Ie will explicitly add to empty <td> elements while other will not.
you can view your page computed source by executing
in the scripting console of IE8's or 9's Developer Tool.(this also works in the Chrome/Safari, Opera FireFly, and FX Firebug scripting consoles).
This is all achademic as there have been changes made to the IE 9 scripting engine and DOM support.
For me this is an example of the disadvantages of using scripted DOM api's to create page markup. On each 'push' the browser has to validate (and sanitise see toStaticHTML) each element. From the developers point of view, there is no tool that will validate your scripts to ensure that they are creating valid markup.. If you submit your page to the w3 validator or the FX Tidy HTML extension it does not see the <script> as markup.
In the IE9 BETA developer tool the script tab shows the computed markup, the HTML tab shows the DOM tree of the page source. There is also improvements in support for innerHTML and createElement, but it is still BETA, so don't bet on it being perfect. Other Beta releases of the other browsers have their issues too. One markup for all browsers has a way to go....
IE6 and 7 are notorious for their lack of DOM api support.
Oh, In IE8 try
Tools>Internet Options, Advanced tab, uncheck "automatically recover from rendering errors using Compatibility View"... this will turn off IE8's markup correction/error handling and should speed rendering.
Monday, February 21, 2011 1:52 PM
Hi All, i have a similar bad behavior of tables with IE8 which doesn't involve scripting.
We dynamically create html pages which mainly consist of a huge table element. As of late we noticed a performance loss at page-load time.
The one thing we did change was to move towards standard compliance.
As a result i wrote a pretty simple console app that generates a simple html page with a 500x500 table element (each <td> having an ID attribute and a random background color). Yeah, i know, its crazy, but unfortunately our customers tend to create things like that :(.
I than checked the load time of the generated html in standards mode and in quirks mode of IE8 with devastating results for the IE8 standards mode.
Quirks: about 12s
Standards: about 75s
Standards (with X-UA-Compatible IE=7): about 14s
Note, this is pure passive html with no scripting and no includes at all. Furthermore, i think i added all recommendations of your previous post (table width, disabled "Automatic recovery" etc.)
With IE9 RC i get weird results. Sometimes the pages loads as fast as 12s but more often it ranges somewhere between 30s and 50s.
Now, Rob, if you are still around, can you confirm the performance difference? And, if possible, provide a workaround?
I will gladly send you my little page generator if it is of any help.
Btw. is there a profiling tool that might help isolating the source of the problem? I mean something that actually tells me that rendering of table cells is slow due to whatever reason.
Thanks in advance, Guido
P.S.: this is the basic structure i'm playing with (just more <tr> and <td> elements)
<!DOCTYPE html> <html> <head> <meta http-equiv="content-type" content="text/html;charset=UTF-8"> <!--<meta http-equiv="X-UA-Compatible" content="IE=Edge">--> <!--<meta http-equiv="X-UA-Compatible" content="IE=7">--> <!--<meta http-equiv="X-UA-Compatible" content="IE=5">--> <title> Performance Test </title> </head><body> <table style="border-collapse:collapse;border-spacing:0px;table-layout:fixed;width:200px;height:50px;"> <colgroup> <col style="width:100px;" /><col style="width:100px;" /> </colgroup><tbody> <tr style="height:50px;"> <td id="C_0_0" style="background-color:#c70005;">0_0</td><td id="C_0_1" style="background-color:#fb3d68;">0_1</td> </tr> </tbody> </table> </body> </html>
- Edited by guido.buecker Monday, February 21, 2011 2:13 PM added html sample code