A Thorn on My Side

The Problem in Brief

I have an ASP.NET 2.0 page whose UI controls are significantly slow.  Please see snapshot below for visual. 

Problem Details

This is only in IE 7. Firefox 2 responds substantially faster. Albeit, a good solution would be to not use IE, but, our clients use it, so, we have to find a solution or palatable work-around.

I want to point out and emphasize that the slowness is after—not while—the page loads. So, this is apparently a client side issue.

The slowness manifests itself when a user

1. clicks on the checkbox controls, they show/hide the check mark very slowly
   
2. selects drop down list controls
   they open up relatively quickly (still slow), but response time is slow when the user scrolls down the list or hovers over items to highlight them; some drop downs have as little as 15 items and some have at most 60 to 80 items.
   
3. simply scrolls the page itself.
   

Slowness is in the order of 4 to 8 second response time running on a local development environment.  It is reproducible and was found on a production, distributed environment.

The slowness is most noticeable when the page is displaying 50 or 100 records. Number of records can be changed with the drop down at the bottom of grid. Please see snapshot below.

Page Details

The page has a list of records displayed in a custom data grid; it also has some peripheral controls that facilitate the overall web app. The list and other controls’ data are fetched from a backend SQL Server 2005 database.

The grid is a custom, ASP.NET server control that renders out to an HTML table. The backend code is in C# 2.0 developed in Visual Studio 2005 (SP1). The grid (among other controls on page and master page) is AJAX’d via Anthem.

The page (in conjunction with the master page), uses Anthem, Prototype/Scriptaculous, and home-grown JS functions.

The following items are, thus far, futile attempts at pinning down the problem:

1. Checked C# code behind.
2. Did some CVS diffs from a suspected release point until now.
3. Checked the JavaScript (non-3^rd party).
   Stepped through with FireBug
4. Took out the CSS classes of the controls on the grid
5. Disabled the viewstate at the page level
6. Set the page to quirks mode.
7. Turned off Phishing filter
8. Disabled all IE add-ons. Also tried to run IE by right-clicking and selecting “Start Without Add-Ons”
9. Configured FFox to run with Trident, just to prove that it’s somehow related to IE. Used IE tab add-on for this.
10. Just to confirm IE issue --> checked CPU usage in taskman as I clicked on controls.  IE goes from 00 to 55.  FFox goes from 00 to 05. 
11. Disabled JS in IE --> ran a lot faster.  Just to confirm issue is also somehow JS related.
12. Ran an MS memory leaks detector utility in IE.  No leaks detected.
13. Took out all Anthem calls and references, no luck.
14. Tried using scriptaculous 1.8.1/prototype 1.6.0.1 bundle.  No luck.
15. Took out all prototype and scriptaculous calls and references, went really fast then.  As soon as we put just the prototype reference (via script tag) back (no function calls), it slowed down again.
16. Did much research on google. Found pages specifying that prototype and IE don’t play well. One page that really stood out is at:

    http://crisp.tweakblogs.net/blog/prototype-ie-and-the-cost-of-element-punt-extend().html

    Especially the paragraph that I copied here from above site for quick reference:
    Whenever an element is targetted using prototype in IE prototype handsomly extends some usefull methods and properties to the element object which is quite practical but comes with a cost. When using getElementsByClassName that cost is even higher because basically at the first execution all elements in the document will be extended, even when they are not selected in the end-result.

Snapshot