jQuery object: to cache or not to cache?

Question

I have some trouble that comes from my Javascript (JS) codes, since I sometimes need to access the same DOM elements more than once in the same function. Some reasoning is a

Answer 1

In JavaScript, functions are generally short-lived—especially when hosted by a browser. However, a function’s scope might outlive the function. This happens, for example, when you create a closure. If you want to prevent a jQuery object from being referenced for a long time, you can assign null to any variables that reference it when you are done with that variable or use indirection to create your closures. For example:

var createHandler = function (someClosedOverValue) {
    return function () {
        doSomethingWith(someClosedOverValue);
    };
}

var blah = function () {
    var myObject = jQuery('blah');

    // We want to enable the closure to access 'red' but not keep
    // myObject alive, so use a special createHandler for it:
    var myClosureWithoutAccessToMyObject = createHandler('red');

    doSomethingElseWith(myObject, myClosureWithoutAccessToMyObject);

    // After this function returns, and assuming doSomethingElseWith() does
    // not itself generate additional references to myObject, myObject
    // will no longer have any references and be elligible for garbage
    // collection.
}

Because jQuery(selector) might end up having to run expensive algorithms or even walk the DOM tree a bit for complex expressions that can’t be handled by the browser directly, it is better to cache the returned object. Also, as others have mentioned, for code clarity, it is better to cache the returned object to avoid typing the selector multiple times. I.e., DRY code is often easier to maintain than WET code.

However, each jQuery object has some amount of overhead. So storing large arrays of jQuery objects in global variables is probably wasteful—unless if you actually need to operate on large numbers of these objects and still treat them as distinct. In such a situation, you might save memory by caching arrays of the DOM elements directly and using the jQuery(DOMElement) constructor which should basically be free when iterating over them.

Though, as people say, you can only know the best approach for your particular case by benchmarking different approaches. It is hard to predict reality even when theory seems sound ;-).

Answer 2

The second is superior. Most importantly, it is cleaner. In the future, if you want to change your selector, you only need to change it one place. Else you need to change it in N places.

Secondly, it should perform better, although a user would only notice for particularly heavy dom, or if you were invoking that function a lot.

Answer 3

You should take a look at http://www.artzstudio.com/2009/04/jquery-performance-rules/

or

http://addyosmani.com/jqprovenperformance/

Answer 4

If you look at this question from a different perspective, the correct answer is obvious.

In the first case, you're duplicating the selection logic in every place it appears. If you change the name of the element, you have to change each occurence. This should be reason enough to not do it. Now you have two options - either you cache the element's selector or the element itself. Using the element as an object makes more sense than using the name.

Performance-wise, I think the effect is negligible. Probably you'll be able to find test results for this particular use-case: caching jQuery objects vs always re-selecting them. Performance might become an issue if you have a large DOM and do a lot of lookups, but you need to see for yourself if that's the case.

If you want to see exactly how much memory your objects are taking up, you can use the Chrome Heap Profiler and check there. I don't know if similar tools are available for other browsers and probably the implementations will vary wildly in performance, especially in IE's case, but it may satisfy your curiosity.

IMO, you should use the second variant, storing the result of the selection in an object, no so much as to improve performance but to have as little duplicate logic as possible.

As for caching $(this), I agree with Nick Craver's answer. As he said there, you should also use chaining where possible - cleans up your code and solves your problem.

Answer 5

I almost always prefer to cache the jQuery object but the benefit varies greatly based on exactly what you are using for your selector. If you are using ids then the benefit is far less than if you are using types of selectors. Also, not all selectors are created equally so try to keep that in mind when you write your selectors.

For example: $('table tr td') is a very poor selector. Try to use context or .find() and it will make a BIG difference.

One thing I like to do is place timers in my code to see just how efficient it is.

var timer = new Date(); 
// code here
console.log('time to complete: ' + (new Date() - timer));

Most cached objects will be performed in less than 2 milliseconds where as brand new selectors take quite a bit longer because you first have to find the element, and then perform the operation.

Answer 6

It is always better to cache the element, if n is greater than 1, cache the element, or chain the operations together (you can do $('#something').something().somethingelse(); for most jQuery operations, since they usually return the wrapped set itself). As an aside, it has become a bit of a standard to name cache variables beginning with a money sign $ so that later in the code it is evident that you are performing an operation on a jQuery set. So you will see a lot of people do var $content = $('#content'); then $content.find('...'); later on.