Requiring context is a good performance rule to use for pages with
tons of nodes. However, I didnt see a performance difference between
providing a string or an object as the context. Perhaps your argument
to throw an exception if a string is provided was for convention only,
in which case it's obviously up to your team.
I ran a few tests using jQuery 1.3.2 on a page with three UL elements
(10,000 list item child nodes each) and ran selections on all of the
list items from the first UL.
$('#listing .list_item'); // Result: ~44ms (time
increases directly with total amount of page nodes)
$('.list_item','#listing'); // Result ~18ms (time
stays
relatively constant for all three other cases regardless of page size)
$('.list_item',$('#listing')); // Result ~18ms
$('.list_item',$('#listing')[0]); // Result ~18ms
In the end the source code sums it up nicely:
// HANDLE: $(expr, [context])
// (which is just equivalent to: $(content).find(expr)
} else
return jQuery( context ).find( selector );
So however your team uses selectors, it will all run through the same
selector code block where jQuery tests for selector type (string,
jQuery object). As long as you are supplying a context, performance
between the different types (string, jQuery object) seems to be
negligible. My 2cents.
Really enjoying the performance gains with context, BTW.
On 20 Aug, 06:04, DBJDBJ <dbj...@gmail.com> wrote:
> Few months ago we discussed here this very point.
> Also ... for my team I introduced jQuery.strict = true; // or false
> If it is true then context must be given and it *must* be a valid dom
> node.
> Otherwise an exception is thrown.
> This change was added to the jQ code. After 2 days of mad exception
> fire-fighting, this (pretty complex) web app started behaving. The
> issue was that a) hardly any one was using context b) of remining 2
> developers, no one has used it by passing a dom node. While in the
> same time app size was exponentially growing.
>
> So, for me the value of the idea of the context is proven. It is only
> that it has very unfortunate name, and also that it is poorly
> documented and explained. Until one looks into the code and sees the
> find() usage. Then everything becomes clear, but not before.
>
> Brandon has written a post which is good. It is only that I have a
> problem with the necessity to have this post ;o)
> In essence Brandon shows (by now) the obvious: dom node should be
> allways passed as the "context" argument. After the post one can see
> an "sea" of comments where this difference between "correct" and
> corect, context is explained. Good.
> But. Is it now trhat we have to adhere to :
> 1:using the context "correctly" (in quotes)
> or is it
> 2:using the context correctly ?
> IF(2) THEN
> Why not just enforcing this in jQ 1.3.3 ?
> var context = $('#primary')[0];
> $('a', context); // OK
> $('a', "#primary"); // throw an exception
> END IF
>
> (repeat: consistent use of dom nodes as a contexts, made our large
> pages behave again, with jQuery)
>
> What is the point of allowing incorrect usage?
> Or is it "incorrect" usage ;o)
>
> -- DBJ
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
