IE 8 Initialization Issue

mantusingh

Hi i am a great fan of datatables and am utilizing it in one of the internal applications in my company.
I need to fetch and display large number of records on the client side so that users can filter and analyze data.
I may need to bind till 4000 records. But at 500 records(11 columns all sortable and searchable with default sort) itself , IE 8 is taking close to 60 secs(with good CPU usage and tab seems to freeze) where as Chrome and Mozilla takes just a sec to do the same.
Since IE is going to be the primary browser used, i need a fix for it.
Any help in this regard will be very much appreciated.

mantusingh

Just to update regarding the various versions used
Jquery ->1.4.2
Datatables min.js->1.7.0

I tried with the latest 1.7.3 datatables version and it takes close to 30 secs.

allan

Are you doing this in a hidden element (i.e. display:none) - we've found before in the forum that if a table is hidden during initialisation, then IE is amazingly slow at parsing it. Setting the table to being visible might well speed it up significantly.

Failing that, then is server-side processing an option?

Allan

mantusingh

Hi Allan ..thanks for your quick response. Appreciate it.
Some quick facts check..
Target No of rows:1856
Time Taken IE8 : 130secs
I am creating the html table data dynamically based upon JSON response, inside a div which was set to "display:none" to enable on demand display.
I made the DIV visible always which reduced the time taken to 120secs and when i make the empty table also present on the page prior to loading it, the time taken falls to 109 secs. This wouldn't be acceptable to business users plus on sorting the grid IE throws an ugly message stating "Do you wanna stop the execution of a script which may freeze the page...."
In order to avoid frequent server side calls , i had moved from traditional asp.net grids to datatables :).
IE sucks..can i do anything else to speed it up ?

allan

I would have expected a much bigger improvement in the time needed with it being visible in IE8. But I guess that's how it goes :-(. So things ot make it faster - I'm honestly not sure - DataTables is fairly optimised already - you could try disabling the sorting classes ( http://datatables.net/usage/features#bSortClasses ), but I'd be surprised it that made a huge difference. Beyond that, I'd suggest profiling the app to see where in the code it is running slow. It might be useful if you can give us a link to it as well.

Allan

mantusingh

hi allan
I found the major culprit. The flag "bAutoWidth" was not set as false hence the function "_fnCalculateColumnWidths" was taking close to 30 secs to complete the calculation for 460 records. On setting it to false the time taken is reduced to around 6 secs. bSortClasses didn't have any major effect. I am putting the configuration of the datatable below..
configParams = {
"bSort": true,
"bAutoWidth": false,
"iDisplayLength":50,
"bSortClasses":false,
"bProcessing": true,
"oLanguage": {
"sSearch": "Filter:"
},
"aaSorting": [[1, 'asc']],
"aoColumns": [
{ "sWidth": "4%", "bSortable": false, "bSearchable": false },
{ "sWidth": "6%", "bSortable": true, "bSearchable": true },
{ "sWidth": "6%", "bSortable": true, "bSearchable": true },
{ "sWidth": "4%", "bSortable": true, "bSearchable": true },
{ "sWidth": "4%", "bSortable": true, "bSearchable": true },
{ "sWidth": "4%", "bSortable": true, "bSearchable": true },
{ "sWidth": "4%", "bSortable": true, "bSearchable": true },
{ "sWidth": "10%", "bSortable": true, "bSearchable": true },
{ "sWidth": "4%", "bSortable": true, "bSearchable": true },
{ "sWidth": "4%", "bSortable": true, "bSearchable": true },
{ "sWidth": "4%", "bSortable": true, "bSearchable": true },
{ "sWidth": "4%", "bSortable": true, "bSearchable": true },
{ "sWidth": "4%", "bSortable": true, "bSearchable": true },
{ "sWidth": "4%", "bSortable": true, "bSearchable": true },
{ "sWidth": "4%", "bSortable": false, "bSearchable": false }
]
};
On checking with IE 8 profiler i see the following results
datatable
each
each
Function.call
JScript - window script block
JScript - window script block
css --------------> (Takes 50% of time in this case 3 secs)
isFunction
_fnInitalise ---> (Takes another 1.5 secs)
_fnGatherData --> (Takes .9 secs)

Please suggest any improvements if you can see from the data provided above.
Even if this was acceptable the subsequent sorting is taking time and IE 8 throws an ugly message stating script may have become unresponsive. Any guidelines for speeding up sort in terms of null data etc ?

allan

Wow that's a big difference, thanks for spotting that. I think it probably comes down to IE just being very slow, and not being able to do much about it. All it does is find the longest string in a column - not particularly a heavy thing for it to do... There might be a way I can optimise the finding of the longest string after the first run, but not the first run that I can think of. Likewise, I'm not sure what can be done to speed up the sorting (or I would have done it!). Server-side processing?

Allan

Marshall

I found this thread when encountering a similar problem with sorts but on IE, only. I've found that on IE 8, using eval() seems to be particularly slow. I haven't run it through a profiler, but switching the default sort routine from the standard routine to the "Non-eval() sorting" routine in function _fnSort() allowed IE to run without complaint. I simply changed the conditional from:
if ( !window.runtime )
to
if ( !window.runtime && !$.browser.msie )

and the slow-running script warnings vanish. It's not the nicest approach since I'm changing the library source code and am splitting code by browser type, but it is working.

This is all on version: 1.7.3

mortb

WOW!

Marshall's comment really helped me out :)

I'm currently using datatables for a project where I display 900 rows in 11 columns.
In the table I have a couple of columns that display either sparse data (many cells in these are empty) or a repetitive list of peoples' names. When I sorted those repetitive and sparse columns I got this message:

---------------------------
Windows Internet Explorer
---------------------------
Stop running this script?

A script on this page is causing your web browser to run slowly.
If it continues to run, your computer might become
unresponsive.

According to this article, http://support.microsoft.com/kb/175500, the message is shown when over 5 000 000 (!) statements are executed between event handling. The profiler in IE8 Develper tools (comes standard with the browser - just press F12) told me that the most time was spent in "string-asc"

So I, desperate for a solution, rewrote my code to use an array for data instead of the DOM. It made message appear less, but did not solve the problem. I added [code]"aaSorting": new Array()[/code] in the constructor to disable any default sorting when loading which also helped but neither solved it.

I was considering to implement server side processing when I read this. Now I added !$.browser.msie and it just works, no extra code to be written!
Being on a deadline that ended yesterday this really saves my day :)

THANKS A MILLION!

And to Allan - thanks for spending your time building a splendid product!

Marshall

Good, glad it helped!

Another surprise element that really lags on IE is JQuery's "inArray" method. The 'eval' sort method in DataTables leverages that function for every record and according to IE's profiler it's taking many times the processing time on IE8 to run through my test data set with that, than without it. I've found some talk online about JQuery inArray() inefficiencies in IE, but nothing that seems this extreme. I don't know if there's a deeper reason behind this, or if there is a way to gain efficiencies by using a different approach.

Also very odd, Firefox by contrast is definitely running a bit faster using the 'eval' version, so IE seems to be in direct opposition. If anyone has any knowledge about the browsers' inner workings and what could cause this, I'd be curious to hear it.

mortb

Yeah, I also noticed that about inArray when profiling.

The reason may be that there is no Array.indexOf(..) function in Microsoft JScript, so the code in JQuery that gets executed for in the JQuery library inArray is the for loop which hardly is as fast as a native implementation.
Firefox has a native implementation.

That may well be the stem to the IE performance problems when sorting.

Allan:
maybe the if [code]( !window.runtime && !$.browser.msie )[/code] should be added to datatables to avoid eval sorting in IE?

kpcrash

I was having a similar problem the last day or two and realized that the IE message was only appearing when there were columns that had null values or where I was using   to make the cell show correctly.
I have changed the loops to show a value of "None" or just a space when there is no data and the script is phenomenally faster in IE and no more script taking too long errors. Perhaps the script could somehow compensate for this? But I'm not sure there's much more you can do at this point.
Ex.
[code]




[/code]
Works great

[code]



[/code]

Will cause the error in IE if there is no value. The script still works, just the annoyance of the error.

mantusingh

Thanks Marshall...it worked for me.
Allan on MortB 's point would this fix get added to the subsequent release...

allan

Hi all,

Just a quick note to say I'm not ignoring this one :-) I'm very much following it with interest. It will take a little more time for me to investigate a bit more what is happening here, and what the best way forward is, but certainly it looks like the standard sort is clocking up the computation count rather quickly, where as the AIR sort is much simpler (and I suspect not quite as complete, but only in edge cases) and so easier on the CPU... I'll come back with more when I've looked at it closer!

Regards,
Allan

PJ

Yeah!

Marshall's tweak took care of the exact same issue I had.

allan

Hi all,

I've just committed a change to DataTables in which I've effectively re-written the sorting implementation that I've been using. There is no longer any use of $.inArray, and I've removed the eval() sort as well (I added a few improvements to the non-eval version and it is at least as good, slightly better in some cases). So with this alteration all browsers should see a benefit in speed, while also having stable sorting :-).

All unit tests are passing with this change, so it's safe to use in a production environment. You can grab this updated version from the downloads page: http://datatables.net/download/ . There are a few other changes I want to make before releasing 1.7.5, but this change will be included when it is.

Regards,
Allan

PaoloValladolid

Props to Marshall - his hack works great for me too!

Allan, thanks as always for your work on Datatables.

mortb

Just now checking back on this. Allan: Glad you find way to make the sorting faster :)

mantusingh

hello allan and folks in this thread,
I am revisiting this thread coz i am trying to implement the same with the latest version of datatables.
The javascript warning on browser is gone , thats great and thank you all for that.
But still the initialization is painfully slow in IE 8.
It takes 6 seconds to load 450 rows of information and right now when i check with IE profiler i see the following things consuming time
css -> 2.3 secs
_fnGatherData -> .9 seconds
_fnDraw -> .7 seconds

Is there any way to optimize this further . Following is the confuration used.
{
"bSort": true,
"bAutoWidth": false,
"iDisplayLength": 10,
//"bSortClasses":false,
"bProcessing": true,
"oLanguage": {
"sSearch": "Filter:"
},
"aaSorting": [[1, 'asc']],
"aoColumns": [
{ "sWidth": "4%", "bSortable": false, "bSearchable": false },
{ "sWidth": "16%", "bSortable": true, "bSearchable": true },
{ "sWidth": "6%", "bSortable": true, "bSearchable": true },
{ "sWidth": "4%", "bSortable": true, "bSearchable": true },
{ "sWidth": "4%", "bSortable": true, "bSearchable": true },
{ "sWidth": "4%", "bSortable": true, "bSearchable": true },
{ "sWidth": "4%", "bSortable": true, "bSearchable": true },
{ "sWidth": "10%", "bSortable": true, "bSearchable": true },
{ "sWidth": "4%", "bSortable": true, "bSearchable": true },
{ "sWidth": "4%", "bSortable": true, "bSearchable": true },
{ "sWidth": "4%", "bSortable": true, "bSearchable": true },
{ "sWidth": "4%", "bSortable": true, "bSearchable": true },
{ "sWidth": "4%", "bSortable": true, "bSearchable": true },
{ "sWidth": "4%", "bSortable": false, "bSearchable": false }
]
};
}

Also the IE 8 freezes for a second or two and then regains consciousness , i dont have a clue how to keep user notified as to something is getting processed, as from javascript perspective the executionis over so my overlay progress bar disappears.
Also what is the unit test mechanism do you use for your js libraries .
Thanks once again and great work Allan.

allan

Unit testing is done by a framework I wrote specifically for DataTables: http://datatables.net/development/testing . It's included in the DataTables package, so if you want to use it, please feel free!

For a speed point of view - I would generally expect _fnGatherData to be the longest in it's execution. But that seems "okay" (as far as IE8 goes). You could possibly try removing the stripe classes and seeing if that helps... But for just 450 rows, that seems like a very long time. Are you doing the initialisation in a hidden (display:none) element - we've found in the forum before that IE is _very_ slow at doing that.

Beyond that, disabling sorting might be interesting to see if that helps, but it could be that you are hitting the boundary of what IE8 can do with client-side processing.

Allan

mantusingh

hello allan,
thanks for your inputs.
The problem lies with IE 8 DOM manipulation. It takes incredibly long time for IE 8(Standards Mode)
to add the complete table to the div(visible) in the page. The whole browser freezes until
the table gets added to the DOM. Are there any ways to speed it up.
I am appending to the DOM just once after constructing the complete table, have set the width to
a relative value of 99% and the table has a tbody too.
Both [code]$("#dvTest").append(tableHTML); or $("#dvTest").html(tableHTML);[/code] take the same time.
Thanks once again Allan.

akbarehsan

Hi Everyone,

Can anyone clarify what Marshall changed and where in his post of * Marshall * CommentTimeNov 2nd 2010"?

I have the MSIE script error and am not able to figure out where to change and what? I am using JQuery DataTables 1.8.

Thanks,

Akbar

anjibman

I am having same script error in IE. Where is the change we have to make?
I am using version 1.7.6

allan

Just to check - you are getting a warning about the script taking a long time to execute, rather than a script error are you? If its taking and long time, perhaps like how many rows you have etc? Have you considered server-side processing if you have a lot of rows. How long does it take - and is the table visible during initialisation?

Allan

anjibman

I am getting
"The page takes so long to display that the Windows Internet Explorer message.
Stop running this script?
A script on this page is causing your web browser to run slowly."
I have more than 8000 rows.
For server-side processing how to achieve that I am using Sturts 1.3.8.
Yes table is visible