6

I found this solution for a case-insensitive jQuery :contains selector on StackOverflow. It works great, however it comes at the cost of performance. Does anyone else find this solution to be a bit slow?

I'm using the :contains selector to search a table. The user types a search string into a textbox. For each keystroke, it searches the table for that string, showing only the rows that contain that string via the :contains selector. Before implementing the case-insensitive solution, this search was quick and snappy. Now with this solution, it locks up for a brief moment after each keystroke.

Any ideas on how this solution could be sped up?

Community
  • 1
  • 1
John
  • 9,254
  • 12
  • 54
  • 75

5 Answers5

10

I found another solution of the case-insensitive search on Google (see Eric Phan) which varies slightly from the one I was originally using.

Original:

return jQuery(a).text().toUpperCase().indexOf(m[3].toUpperCase())>=0;

EricPhan:

return (a.textContent || a.innerText || "").toLowerCase().indexOf(m[3].toLowerCase())>=0;

Comparing the two, you can see Eric Phan's solution accesses the DOM attributes directly and uses toLowerCase() instead of toUpperCase(). The latter doesn't really matter, but the former is what really improved the performance of the case-insensitive search. Just changing the original solution to use (a.textContent || a.innerText || "") instead of jQuery(a).text() made all the difference!

Now I'm a bit curious, so here's a follow up question: What's the deal with jQuery.text()? Why's it so slow? I have my assumptions, but I'd love to hear what the experts have to say.

Lastly, thanks to everyone who responded. I appreicate your help. =)

John
  • 9,254
  • 12
  • 54
  • 75
  • This is an incredibly old post and probably not relevant to reality at all, but if i had to pull out my time machine. My guess is invoking jquery on that specific data/DOM resulted in a javascript exception which jquery handled internally. Whereas your change to the multi-legged check likely short circuited instead of raising an exception that needed caught. – Chris Marisic Jun 21 '16 at 20:46
6

You could try to check the selector only once, after the user has stopped typing for a specified amount of time, not for every keystroke.

For example, a simple implementation:

Usage:

$("#textboxId").keyup(function () {
  typewatch(function () {
    // executed only 500 ms after the user stopped typing.
  }, 500);

Implementation:

var typewatch = function(){
    var timer = 0;  // store the timer id
    return function(callback, ms){
        clearTimeout (timer);  // if the function is called before the timeout
        timer = setTimeout(callback, ms); // clear the timer and start it over
    }  
}();
Christian C. Salvadó
  • 807,428
  • 183
  • 922
  • 838
  • Thanks CMS! I liked this solution very much; simple and effective. However, there was still a longer than specified delay after my last keystroke. I took another look on Google and found different version of the case-*insensitive* search that actually matches the performance of the default case-*sensitive* search (see my answer below). Nevertheless, I'm keeping your solution in my back pocket. I'll definitely need something like this later on. =) – John Sep 11 '09 at 16:06
1

you could try not checking after each keystroke, but maybe a second after the last keystroke has been pressed. this way you're not constantly checking while the user is typing but rather checking when the user is finished or pausing typing.

Jason
  • 51,583
  • 38
  • 133
  • 185
1

here's a follow up question: What's the deal with jQuery.text()? Why's it so slow?

I suspect that it's slow due to the $(a) (converting the DOM element to a jQuery object) and not the .text().

Paul
  • 544
  • 4
  • 12
0

To add to what jason has said, you can try using this plugin to accomplish that.

mkoryak
  • 57,086
  • 61
  • 201
  • 257