slow sorting in firefox

wcmanes

When pagination is set to show 100 rows, sorting in firefox (3.5) seems very slow. It takes 2-3 seconds for display to refresh. The response time in IE8 and Safari is much quicker (under 1 sec, no real noticeable delay). Stepping through the code in firebug, this is definitely happening in the _fnsort function, but firebug seems unable to step into this procedure.

Multiple users have reported this and it happens in FF with or without firebug enabled/installed. Is there any reason this would be so obviously different in FF only? Is there anything that can be done besides server-side processing? I have less than 200 hundred rows with 7 columns, so it's not really a lot of data. I think it must be a drawing issues as the same number of rows are sorted no matter how many are displayed...

Bill

wcmanes

Oh, one more pertinent piece of information...

I tried with and without sort classes applied. No apparent change in speed based on this.

allan

Hi wcmanes,

wow - 2-3 seconds to sort on only 200 rows really is slow. I've just tried this in Firefox 3.5 using about 250 records and it appears to work okay with my data set, and basic initialisation. Are you using a complex sorting function or anything like that, or is it as simple as $({selector}).dataTable(); ?

Are you able to provide a link to the page which is running slow? The _fnSort function will construct a dynamic function to run (unless you are using AIR - which you aren't...) which is why it's harder to debug further down into the sorting. If you wanted to you could force it to use AIR style sorting by doing window.runtime = true, so your profiler will then pick up the sort functions.

Regards,
Allan

wcmanes

It's actually just over 100 rows and I'm using standard initialization and sort. Have run firebug profiler and it shows a total time of about 100ms, which doesn't make sense to me (some data below). As I said, I only see the slow response in FF.

Tried setting window.runtime and I do not see any change. I will send you a PM with a link to the app.

Profile (107.621ms, 16007 calls)
_fnDraw 1 29.06% 31.271ms jquery.d...Tables.js (line 2503)
remove() 950 13.85% 14.906ms jquery-1.3.2.js (line 720)
add() 237 7.41% 7.977ms jquery-1.3.2.js (line 713)
has() 1305 5.43% 5.839ms jquery-1.3.2.js (line 730)
filter() 219 4.45% 4.786ms jquery-1.3.2.js (line 1580)
Sizzle() 219 3.3% 3.548ms jquery-1.3.2.js (line 1426)
find() 218 3.07% 3.305ms jquery-1.3.2.js (line 1549)
inArray() 1187 2.93% 3.148ms jquery-1.3.2.js (line 1087)
removeClass() 950 2.87% 3.088ms jquery-1.3.2.js (line 1230)
grep() 950 2.39% 2.571ms jquery-1.3.2.js (line 1135)
(?)() 1068 2.11% 2.269ms jquery-1.3.2.js (line 723)
each() 462 2.09% 2.252ms jquery-1.3.2.js (line 672)
isXML() 876 1.87% 2.012ms jquery-1.3.2.js (line 2339)
add() 223 1.54% 1.654ms jquery-1.3.2.js (line 712)
_fnDataToSearch 832 1.41% 1.514ms jquery.d...Tables.js (line 3760)
POS() 834 1.29% 1.383ms jquery-1.3.2.js (line 2043)
_fnBuildSearchArray 1 1.19% 1.279ms jquery.d...Tables.js (line 3731)
unique() 2 1.11% 1.192ms jquery-1.3.2.js (line 1114)
data() 938 1.07% 1.147ms jquery-1.3.2.js (line 1275)


Thanks for your great work.
Bill

wcmanes

Did some more debugging. The major issue is related to this code in _fnDraw in the loop through the displayed rows:

/* Remove any old stripping classes and then add the new one */
if ( iStrips !== 0 )
{
$(nRow).removeClass( oSettings.asStripClasses.join(' ') );
$(nRow).addClass( oSettings.asStripClasses[ iRowCount % iStrips ] );
}

Takes about 900ms for the _fnDraw function with 100 rows displayed.


I changed this code to:

(before loop)
var ia = 0;
var ir = 1;

(in loop)
/* Remove any old stripping classes and then add the new one */
if ( iStrips !== 0 )
{
if ( !$(nRow).hasClass( oSettings.asStripClasses[ia]) ) {
$(nRow).removeClass( oSettings.asStripClasses[ir] ).addClass( oSettings.asStripClasses[ia] );
}
ir = ia;
ia = 1 - ia;
}

This modification reduces the time for _fnDraw to between 100ms and 500ms (depending on how many rows need to have their class updated). This is not as "general purpose" as the original code because it assumes there are always 2 classes (even and odd), which as far as I can tell is always true. It does make a noticeable improvement in the sort response time (from 2-3 sec to 1-2 sec). I think this is acceptable, but it may be able to be improved further.

Bill

allan

Hi Bill,

I like it! Nice one - thanks for following up on this. It's given me a few ideas for how to speed the draw up as well, and I'll give them a go, and post back with the results. Certainly your work here is of huge benefit to the project as a whole given how "core" this function is :-) Thanks.

Regards,
Allan

allan

Hi Bill,

A quick update on this - What I've done is basically the same as you've got above, but removed the need for the $().hasClass method call by storing which class is being used for a row in the aoData array. This removes the need for one more DOM interaction, and also one more jQuery call - which should hopefully speed things up just a little bit more :-)

For a few few quick measurements (Firefox 3.5/Mac with 227 records) I'm getting:

Old method: 205mS
New method: 175mS

So a substantial decrease. I'll looks to see if there are further ways to speed things up a bit - I'm sure there probably are :-)

Regards and thanks again,
Allan

wcmanes

Thanks Allan. I would be glad to try out your updates if there is a way I can get your latest code.

Bill

allan

Hi Bill,

I've just sent over a copy of the latest development DataTables file. It's got the change in there, so hopefully you'll be able to see a little improvement (although probably not much more than your own method).

Regards,
Allan