fnUpdate performance
fnUpdate performance
JohnnyRico
Posts: 1Questions: 0Answers: 0
My last attempt to create this topic was eaten by my session expiring, so I'll try to keep it brief this time.
I have an AJAX process which updates a ~80 line table using fnUpdate and a delayed redraw that causes a complete lockup in the clients browser for about 2.5 seconds. The client is running IE 7 on Windows 2003/XP.
I've profiled this in firebug and the clear culprit is the fact that fnUpdate rebuilds the entire search "database" for the table per call, which is something like O(n) on the number of rows of the table. That means that the whole update ends up being O(n^2) where n is close to 80, hence the enormous script lockup.
It should be relatively easy to make it so each call to fnUpdate only updates the search data for that one line, instead of the whole table. Alternatively, you could expose the timing of when to update the search "database" much like what was done for the table redraw.
I have an AJAX process which updates a ~80 line table using fnUpdate and a delayed redraw that causes a complete lockup in the clients browser for about 2.5 seconds. The client is running IE 7 on Windows 2003/XP.
I've profiled this in firebug and the clear culprit is the fact that fnUpdate rebuilds the entire search "database" for the table per call, which is something like O(n) on the number of rows of the table. That means that the whole update ends up being O(n^2) where n is close to 80, hence the enormous script lockup.
It should be relatively easy to make it so each call to fnUpdate only updates the search data for that one line, instead of the whole table. Alternatively, you could expose the timing of when to update the search "database" much like what was done for the table redraw.
This discussion has been closed.
Replies
Ouch yes, fnUpdate is really rather inefficient if it's being called a lot like that. A couple of options strike me as being immediately suitable - the first would be to have a custom plug-in function which does most of the things that fnUpdate does (could be optimised even more depending on your exact situation), but doesn't call _fnBuildSearchArray() - that could be done at the end of the update sequence by a different API function. Another option might be to hack fnUpdate to have an extra parameter which will tell it to update (or not) the search array (much like bDraw is used for conditionally redrawing that table).
Regards,
Allan