IE8 "Script running slowly" message when loading data in large ListGrid

[ssouthwell]

SmartClient Version: v9.0p_2013-09-22/Pro Deployment (built 2013-09-22)
Internet Explorer 8

We have a listgrid where we are trying to retrieve all data at once, due to some complicating factors on the server side that makes it more efficient, and due to the fact that we need to show a grid summary row with field totals.

The number of records we're talking about is as few as 884 rows with 23 columns.

Only in Internet Explorer 8 (Not IE10 running in IE8 mode) we experience a problem where the datasource comes back with data and the user gets a message in JavaScript: "A script on this page is causing IE to run slowly. If it continues to run, your computer may become unresponsive." As soon as the user dismisses this message the grid renders immediately.

I have looked through the forums here to see if I can figure out what may be causing this. I understand that in a perfect world, my grid would be incrementally obtaining the data, but I don't have that option here, due to the need for summary information and because my datasource takes the same length of time to run regardless of whether I get the whole recordset or just a subset.

Failing that, I have seen a few posts on here mentioning some grid settings like autoFitData. My grid has this:

 autoFitData : "both",
autoFitMaxRecords : 20,

But even taking out the above, we still get the error.

We also have this:

 showAllRecords: false,
showAllColumns: false,

I wondered if it might have something to do with the fact that we are using a grid summary:

 showGridSummary : true,

Taking that out just to test, we still get the error.

Aside from this, the grid works well in other browsers, and even works well in IE8, once the user dismisses the JavaScript warning about the slow running script.

Is there anything else I can check with my grid? What else can slow down a grid, or make it run so much JavaScript that it would throw this kind of error?

[Isomorphic]

It's not that the code is slow, IE's detection mechanism is simply broken. It's based on a crude instruction count, so it will literally show a dialog for an implementation that is faster but not show a dialog for one that is slower. This dialog has also been shown to appear in some cases when less than 0.2 seconds of wall clock time have elapsed.

The only general strategy here is to break up the computation by using JavaScript's setTimeout() API. At the application level, you can do things like draw the grid empty, setTimeout, then provide the data. Or further, provide the data, then setTimeout, then enable summaries.

[ssouthwell]

Followup

So, then if IE8 lets say is balking because it's hit its 5 million instruction limit, you don't think there is anything weird about having that many instructions for such a fairly small record set?

Are there any sort of gotcha settings in a grid that could cause more instructions to be run per row than normal?

But back to your strategy of setTimeout: We are drawing the grid and waiting until it is all rendered before we do a fetchData() on it. Would it be advisable to maybe disconnect the datasource from the grid, and retrieve it all into a resultset first, then incrementally add records from the resultset into the grid's data 200-300 records at a time?

[Isomorphic]

So, then if IE8 lets say is balking because it's hit its 5 million instruction limit, you don't think there is anything weird about having that many instructions for such a fairly small record set?

Not in the slightest. There are many, many steps going on in rendering such a grid, and the fastest code in wall clock time often executes more instructions, especially in IE.

Are there any sort of gotcha settings in a grid that could cause more instructions to be run per row than normal?

Every feature that is active causes more instructions. There are no particular gotchas.

But back to your strategy of setTimeout: We are drawing the grid and waiting until it is all rendered before we do a fetchData() on it. Would it be advisable to maybe disconnect the datasource from the grid, and retrieve it all into a resultset first, then incrementally add records from the resultset into the grid's data 200-300 records at a time?

Doing the fetch and populating a ResultSet, sorting the ResultSet to match the grid, then passing the ResultSet via setData() would break out a small amount of processing. Adding records in batches probably would not help; you still end up running summaries, sort, etc over the complete dataset.