That's horribly slow! How fast is it with DataTables disabled? Are you initialising the DataTable in an element that is display:none? I seen before that IE does something very odd with parsing information from the DOM in elements which are not displayed.
With DataTables disabled, it comes in about 1 second. I have the display set to 'block'. Just as an experiment, I set it to none and then returned it to block after initialising the DataTable and that took the time up to [drum roll please] 40 seconds! Sorry, I don't have a public link up yet.
Since I am refactoring to replace PHP with python/django, I think I'll change the logic to send the extra info in , so I can take advantage of the bDeferRender option. Many thanks for answering (I dropped a few greenbacks in the tip jar yesterday)
Very interesting that DataTables is taking so long. Not surprised that to look 40 seconds with display:none, but 16 seconds is a long time for use 290 records when visible - I really wouldn't have expected that! If you are able to give me a link in future, I'd be most interesting in seeing if I can discover some method of improving now DataTables operates.
So I took the example here with the branched version and saved locally and changed to use my JSON and my headers. With the exception that this branch has to have a 2 dimensional array as opposed to what I use a array of objects....it works perfect. Problem is using the latest 1.9.2 within my app with array of objects.....it does not seem to work at all. Has this not been incorporated into 1.9.2? If hit has does it have to be a 2 dimensional array?
Yes, I was wondering if the bDeferRender was incorporated in 1.9.x.
Currently I have 4,000 and client wants to paginate 1,000
but the staging table in the DB could in theory has as many as 30,000.
My first test here is only using pages of 100 but it performs as slow as it does without bDeferRender.
16 seconds for IE, 6 seconds for FF
here are the options I am using...
(I've tried commenting out the fnRender seems to have no affect.)
I display 15 columns but send back 17 data points per object.
Okay, if you need to support up to 30'000 rows and IE, I would very much suggest that you use server-side processing, which will easily cope with millions of rows (even in IE, since the server does the work!): http://datatables.net/usage/server-side .
Actually I am using server side processing...
bServerSide: true,
paginating server side at 200 is about 5 seconds in IE which is doable.
But paginating 1,000 (client spec) is 16 seconds in IE which is not so doable to have to wait 16 seconds for each page click.
So when I saw these examples stuffed my JSON and number columns in the example with the branch and with 4,000 rows and 1,000 ppage it is awesome fast. I'd be happy with that speed but not when I use in my app with 1.9.2 and server side. It is not Network related as FF is only 4 seconds for the same settings. It is seeming a rendering issue in IE.
BTW I feel client side processing is REALLY fast even with greater than 10,000 rows with the branched example. I am waiting 16 seconds for the first page of 1,000 records to display with server side requests (4K total in DB). So for me if I could send the entire 4K back all at once then quickly show the first 1,000 as fast as the examples (which are showing 10,000) I'd be happy. However, I am only sending 1,000 back now and it is VERY slow to render even though the JSON is back in less than a second. SO I am assuming some combination of settings is my issue, as why would a 1,000 page from server take 16 seconds while 10,000 in local file take 1 second to display a page of 1,000 of them? Other than the two different versions (branch and 1.9.2) the main thing different is Array of Objects vs 2D Array.
> why would a 1,000 page from server take 16 seconds while 10,000 in local file take 1 second to display a page of 1,000 of them?
Yes I don't understand that. Are they both in a display:none element? We have found in the past that that can kill performance in IE (for reasons only those familiar with the internals of the engine would be able to tell us).
Does it take the server 16 seconds to respond to the request? Or is it 16 seconds for DataTables to paint it? I'm going to guess the former. Is that correct?
> Other than the two different versions (branch and 1.9.2) the main thing different is Array of Objects vs 2D Array.
Objects can be slower because DataTables does a clone of the object (I'm going to offer an option to stop that in future).
Does bDeferRender and/or Scroller require the view-port to be static?
I have sScrollY = sScrollX = 100% it is supposed to stretch with the UI Layout. I wondered if that was why it had little speed affect, perhaps if it does not know the view-port and therefore it cannot tell how many to render...(?) just a hunch.
Some quick answers...
-- No data (at least in FF) is returned within a second.
-- as far as my table is concerned it is created just before the datable using .append() just to be safe I do a .show() before the .dataTable() but it should be visible already and it had no discernible affect.
-- Perhaps it is an issue with array of Objects vs 2D Array...
Yeah I am doing that and it does. But I was noticing that bDeferRender/Scroller examples all have a static viewport not not a dynamic one. Theorizing that my slowness in comparison to the examples was related to that difference.
Unfortunately I am working on a non public site and can't provide a link.
I did attempt to comment out the ColumnFilterWidgets which did not change the result. I then removed the "W" from the sDom which is a cFeature that is used to specify where the ColumnFilterWidgets dropdowns are placed. That sped things up quite a bit. It went from >30 to <5 seconds.
I know that you don't support ColumnFilterWidgets but can you offer any advise on where in the DataTables code I can look to see how the W might be affecting rendering?
Well, I tracked down the offending code in the ColumnFilterWidgets plugin if its fnDraw method.
[code]
$.each(aDistinctOptions, function (i, sOption) {
var sText;
sText = $('' + sOption + '').text();
widget.$Select.append($('').attr('value', sOption).text(sText));
});
[/code]
Both the jQuery append and each are fairly slow in IE when used this way. I did some searching and found an improvement to this code.
[code]
var iLength = aDistinctOptions.length;
var aOptions = [];
var i = 0;
for (var a = 0; a < iLength; a += 1) {
aOptions[i++] = '';
aOptions[i++] = aDistinctOptions[a];
aOptions[i++] = '';
}
widget.$Select.append(aOptions.join(''));
[/code]
Replies
That's horribly slow! How fast is it with DataTables disabled? Are you initialising the DataTable in an element that is display:none? I seen before that IE does something very odd with parsing information from the DOM in elements which are not displayed.
If you have a link, that would be most helpful.
Allan
With DataTables disabled, it comes in about 1 second. I have the display set to 'block'. Just as an experiment, I set it to none and then returned it to block after initialising the DataTable and that took the time up to [drum roll please] 40 seconds! Sorry, I don't have a public link up yet.
Since I am refactoring to replace PHP with python/django, I think I'll change the logic to send the extra info in , so I can take advantage of the bDeferRender option. Many thanks for answering (I dropped a few greenbacks in the tip jar yesterday)
Best
Mike
Very interesting that DataTables is taking so long. Not surprised that to look 40 seconds with display:none, but 16 seconds is a long time for use 290 records when visible - I really wouldn't have expected that! If you are able to give me a link in future, I'd be most interesting in seeing if I can discover some method of improving now DataTables operates.
Regards,
Allan
Sorry for the misinformation...
http://datatables.net/forums/discussion/10334/data-loads-quickly-in-ie8-but-browser-chokes-on-scrolling
How big is your data set (rows and columns)?
Allan
Yes, I was wondering if the bDeferRender was incorporated in 1.9.x.
Currently I have 4,000 and client wants to paginate 1,000
but the staging table in the DB could in theory has as many as 30,000.
My first test here is only using pages of 100 but it performs as slow as it does without bDeferRender.
16 seconds for IE, 6 seconds for FF
here are the options I am using...
(I've tried commenting out the fnRender seems to have no affect.)
I display 15 columns but send back 17 data points per object.
[code]
myTableOptions: {
sAjaxSource : '/xyz/stagetable.do', bAutoWidth: false,
bDeferRender: true, bSortClasses: false,
bProcessing: true, bServerSide: true,
bRetrieve : true, bProcessing : true,
sScrollY : "100%", sScrollX : "100%",
bScrollCollapse : false, bDestroy : true,
bPaginate : true, sDom : "rtip",
aaSorting: [[ 5, "desc" ]],
aoColumns : [
{ mDataProp : "id", sTitle : '', bSortable: false,
bSearchable: false, "sDefaultContent" : '', sClass: 'noClick',
"fnRender" : function(oObj) {
return '';
} },
{ mDataProp : "firstName", sTitle : "First Name", "sDefaultContent" : '' },
{ mDataProp : "lastName", sTitle : "Last Name" },
{ mDataProp : "empId", sTitle : "Emp Id" },
{ mDataProp : "gId", sTitle : "gId" },
{ mDataProp : "tDate", sTitle : "tDate" },
{ mDataProp : "tot", sTitle : "Tot." },
{ mDataProp : "estimatedPrice", sTitle : "Est. Price" },
{ mDataProp : "value", sTitle : "fValue" },
{ mDataProp : "estimatedAmount", sTitle : "Est.Amt" },
{ mDataProp : "commission", sTitle : "Commission" },
{ mDataProp : "type", sTitle : "Type Cd" },
{ mDataProp : "countryCode", sTitle : "Country Cd" },
{ mDataProp : "warningReason", sTitle : "Warnings" },
{ mDataProp : "errorReason", sTitle : "Errors" }
],
fnDrawCallback : function() {
MY.debug('fnDrawCallback STAGING');
MY.resizeDataTable(this);
},
iDisplayLength: 100,
aLengthMenu: [[100, 200, 400], [100, 200, 400]]
},
[/code]
See also http://datatables.net/faqs#speed .
Allan
[code]
$('#stageGridForm').append('');
// set up the stage Detail Table
$('#stageTable').dataTable( MY.myTableOptions );
[/code]
bServerSide: true,
paginating server side at 200 is about 5 seconds in IE which is doable.
But paginating 1,000 (client spec) is 16 seconds in IE which is not so doable to have to wait 16 seconds for each page click.
So when I saw these examples stuffed my JSON and number columns in the example with the branch and with 4,000 rows and 1,000 ppage it is awesome fast. I'd be happy with that speed but not when I use in my app with 1.9.2 and server side. It is not Network related as FF is only 4 seconds for the same settings. It is seeming a rendering issue in IE.
Yes I don't understand that. Are they both in a display:none element? We have found in the past that that can kill performance in IE (for reasons only those familiar with the internals of the engine would be able to tell us).
Does it take the server 16 seconds to respond to the request? Or is it 16 seconds for DataTables to paint it? I'm going to guess the former. Is that correct?
> Other than the two different versions (branch and 1.9.2) the main thing different is Array of Objects vs 2D Array.
Objects can be slower because DataTables does a clone of the object (I'm going to offer an option to stop that in future).
Allan
I have sScrollY = sScrollX = 100% it is supposed to stretch with the UI Layout. I wondered if that was why it had little speed affect, perhaps if it does not know the view-port and therefore it cannot tell how many to render...(?) just a hunch.
Some quick answers...
-- No data (at least in FF) is returned within a second.
-- as far as my table is concerned it is created just before the datable using .append() just to be safe I do a .show() before the .dataTable() but it should be visible already and it had no discernible affect.
-- Perhaps it is an issue with array of Objects vs 2D Array...
Sort of - you need to call fnAdjustColumnSizing to have DataTables recalculate the column widths on a resize event.
Allan
Here's what my init code looks like. Is there anything that I can do to improve performance?
[code]
var oTable = $('#section_mapper').dataTable({
'bServerSide': false,
'sAjaxSource': 'SelectSection/Data',
'bProcessing': true,
'sScrollY': '467px',
'bScrollInfinite': true,
'bScrollCollapse': true,
'bPaginate': false,
'bDeferRender': true,
'bSortCellsTop': false,
'aoColumnDefs': [
{ 'sWidth': '27%', 'aTargets': [0] },
{ 'sWidth': '15%', 'aTargets': [1] },
{ 'sWidth': '25%', 'aTargets': [2] },
{ 'sWidth': '32%', 'aTargets': [3] }
],
'aoColumns': [
{ 'sType': 'html' }, /* needed to fix chrome sort issue */
{ 'sType': 'html' },
{ 'sType': 'html' },
{ 'sType': 'html' },
{
'bSearchable': false,
'bVisible': false
},
{
'bSearchable': false,
'bVisible': false
}
],
'fnRowCallback': function (nRow, aData, iDisplayIndex, iDisplayIndexFull) {
if (aData[hiddenSelectedCol] == 'true') $(nRow).addClass('row_selected').addClass('unselectable');
},
'fnDrawCallback': function (oSettings) {
this.fnSetMenuState();
},
'sDom': 'r<"filters"W><"clear">ti',
'oColumnFilterWidgets': {
'aiExclude': [4, 5]
}
});
[/code]
Is the table hidden when you initialise it? That can kill performance in IE. Can you give us a link please?
Allan
I did attempt to comment out the ColumnFilterWidgets which did not change the result. I then removed the "W" from the sDom which is a cFeature that is used to specify where the ColumnFilterWidgets dropdowns are placed. That sped things up quite a bit. It went from >30 to <5 seconds.
I know that you don't support ColumnFilterWidgets but can you offer any advise on where in the DataTables code I can look to see how the W might be affecting rendering?
Thanks for the response and the great tool!
[code]
$.each(aDistinctOptions, function (i, sOption) {
var sText;
sText = $('' + sOption + '').text();
widget.$Select.append($('').attr('value', sOption).text(sText));
});
[/code]
Both the jQuery append and each are fairly slow in IE when used this way. I did some searching and found an improvement to this code.
[code]
var iLength = aDistinctOptions.length;
var aOptions = [];
var i = 0;
for (var a = 0; a < iLength; a += 1) {
aOptions[i++] = '';
aOptions[i++] = aDistinctOptions[a];
aOptions[i++] = '';
}
widget.$Select.append(aOptions.join(''));
[/code]
I hope this can help someone else out.
Allan