Background processing overhead ideas

rgriffin

Hello all,
I was hoping to start a discussion about what can be done to trim down database calls when doing background processing, in relation to the search filter. For a while now, I have considered that querying the database (default behavior) every keyup is a lot of processing/overhead.

A simple solution would be to modify the core library dataTables.js _fnFeatureHtmlFilter function to count the number of keyups and prevent the search from occurring unless some specified length (such as every 3 characters). This would look something like the following:

[code]
// Capture the number of keyups
var filter_string_length = 0;...

jqFilter.keyup( function(e) {

// Test if the filter length is less than 3 characters
if (filter_string_length < 2)
{
filter_string_length++;
return true;
}
// Test if the filter length is more than 3 characters
else
{
filter_string_length = 0;
}
// Continue searching with a minimum of 3 characters...
[/code]

This is crude and requires modifying the core functionality of the program. I think there must be a better solution.
Your thoughts/ideas?

GregP

Wouldn't be hard to implement a delay before the string is considered complete. Each keyup triggers an interval, and after that interval is reached it is assumed that the user is ready for the search to execute. If the user is just a slow typist, the extra searches won't put them back any further than they are now.

I'll have to implement something like this for a project I'm working on; still haven't looked into the API yet to see if that'll mean modifying the core or not.

jp_noronha

search while surfing is ok and gives a lot to appearence, but in this case i think is overrated. I had to give up using because it proves to be an hazard when there is more than 2000 lines (client-side), it consumes too much time to find and to the user it seems the page has hipcups :)

I use the plugin to force return pon search, no delays and the user isn't surprised with diferent behaviors for the same page when searching (one that returns fast results other that delays, because of the number of lines).

My humble opinion is that search as it is is ok, it works extremelly well for small tables, for greater ones the developer as allways the choice of using plugins

allan

There is a plug-in here which wiil help you out if you don't want to hammer the server on each key press: http://datatables.net/plug-ins/api#fnSetFilteringDelay .

Allan

fbas

here's a simple routine that has worked great for me, and you can use it for all your fnFilter calls (afaik, fnSetFilteringDelay only affects your global sSearch input box)


by only allowing one timer process to send to the server (previous calls are cancelled) a lot of overhead is avoided.
[code]
// singleDelay is used in event handlers to reduce number of AJAX calls
// adds a timer delay before sending AJAX. if new data is offered, that timer is cancelled
// and a new one is created
var iDelay = 600; // miliseconds to call ajax after no new activity
var inDelay = null; // timer handle
function singleDelay(x) {
if (inDelay) clearTimeout(inDelay);

inDelay = setTimeout(x, iDelay);
}
[/code]

usage: very similar to calling setTimeout(), except it limits timers to a single timer at a time
[code]
singleDelay(function() { oTable.fnFilter(value, colnum); });

[/code]


POTENTIAL WEAKNESS: you could, because of the timing issue involved, jump from one column's filter to another, and clobber the previous one, even though you intended to filter on both columns. You could fix this easily by having an array of inDelay timers, one for each sortable column, and one global one for the global sSearch

GregP

Allan, that plugin is about right for what I need! Saves me some development cycles.

Cheers,
Greg

rgriffin

Thanks Allan

allan

One of the oldest API plug-ins that one, and it's a goodie :-)

Allan