> From: Dave Methvin
>
> The implementation is pretty straightforward, but the
> implications are tough to handle. You'd need to store both
> the incoming selector string (assume you don't have to cache
> incoming DOM references) and the context. Then you'd need
> some way to invalidate the cache; I don't think there's any
> workable way that jQuery can figure out whether its cache is
> valid or not.
It sounded like the OP was talking about a DOM element cache, which could
speed up queries even when they aren't identical. But either way there are
some really tricky issues here.
> Judging from the code that is posted on the list, I think we
> could improve performance by encouraging people to use
> chaining and/or keep their own "cache" in a local or global
> variable when it's warranted and safe.
Indeed, if you're talking about the same query repeated when the underlying
DOM hasn't changed, nothing beats simply caching the jQuery result in your
own variable. That's faster than any cache could ever be.
This is the kind of code you're talking about:
function turtle() {
for( var i = 0; i < 42; i++ ) {
$('.foo').append( 'Line ' + i );
}
}
It's trivial to speed this up considerably:
function hare() {
var $foo = $('.foo');
for( var i = 0; i < 42; i++ ) {
$foo.append( 'Line ' + i );
}
}
Note the use of the leading $ in the variable name to indicate that $foo is
a jQuery object. That's a convention I've found to be very helpful,
especially when I need to reference both a straight DOM element and the
corresponding jQuery object. Then I'd use foo for the element itself and
$foo for the jQuery wrapper. This makes it easy to remember which one is
which.
-Mike
_______________________________________________
jQuery mailing list
[email protected]
http://jquery.com/discuss/
