It would definitely make sense of course. What I really wanted was to minimize the impact of this extra- processing on complex selectors. In .closest(), even if you don't use any kind of cache, you parse the selector only once every time you use the function. If the optimization lies jQuery.filter then the cache becomes much more important. Since I'm not sure what kind of caching mechanism to use (would .data () be faster than re-parsing the selector?), I wasn't feeling confident enough to propose this change for .filter().
There was also an optimization in .closest() for position selectors (:first, :last, ...). I don't know what it was here for (I never use such selectors for event delegation), but it wasn't in jQuery.filter. What would you recommend? Louis-Rémi On Aug 17, 10:44 pm, John Resig <jere...@gmail.com> wrote: > I'm curious as to why you only chose to optimize the selectors in .live(). > Why not optimize .is()? or jQuery.filter? Optimizing jQuery.filter would > yield faster results for .filter(), .is(), and .live(). > > --John > > On Mon, Aug 17, 2009 at 1:38 PM, lrbabe <lrb...@gmail.com> wrote: > > > I've made some minor updates to the code to reduce the code size: > > - it now uses the internal jQuery.nodeName function to check for > > simple selectors involving a node name (which is also safer) > > - it checks for simple selectors before checking for position > > selectors > > The size difference for the minified version between the current > > implementation and this new one should be around 250B > > The code is at the same address:http://gist.github.com/168158 > > > I'm also willing to write on learningjquery.com about the new features > > for event delegation introduced in jQuery 1.3: live and closest > > Who should I contact for that purpose? > > > Regards, > > Louis-Rémi Babé > > > On Aug 15, 2:23 am, lrbabe <lrb...@gmail.com> wrote: > > > Thank for your quick answer John, > > > > All right, I take the code of the example, remove the part that > > > updates the counter and wraps the rest with a console.profile() > > > > 1. With the orginal .closest() implementation: > > > - entering the ul: function calls = 76, time = 1.5 to 2.5 ms > > > - moving from a li to a li.blue: calls = 144, time ~= 3.2ms > > > - moving from a li.blue to a li: calls = 103, time ~= 2.2ms > > > - moving from a li to a green span: calls = 124, time ~= 2.2ms > > > - moving from a green span to a red span: calls = 145, time ~= 3.2ms > > > 2. With the modified .closest() implementation: > > > - entering the ul: function calls = 13, time ~= 0.25ms > > > - moving from a li to a li.blue: calls = 27, time ~= 0.55ms > > > - moving from a li.blue to a li: calls = 13, time ~= 0.25ms > > > - moving from a li to a green span: calls = 13, time ~= 0.3ms > > > - moving from a green span to a red span: calls = 13, time ~= 0.3ms > > > > ...and we have only three levels of elements here. > > > > On Aug 15, 1:51 am, John Resig <jere...@gmail.com> wrote: > > > > > An interesting proposition - although before making a change of this > > > > magnitude it would be good to get some performance numbers outlined so > > that > > > > we know how worthwhile it is. > > > > > --John > > > > > On Fri, Aug 14, 2009 at 8:33 PM, lrbabe <lrb...@gmail.com> wrote: > > > > > > Hi, > > > > > > The principle of .closest( selector ) is that it cycles through the > > > > > ancestors of an event target until it finds an element corresponding > > > > > to the event target, or hits the root. > > > > > To check for an element matching the selectors it uses the .is > > > > > ( selector ) function which collects all elements corresponding to > > the > > > > > selector and cycles through them to find if "this" is any of those > > > > > elements. > > > > > > If my memories about my algorithm lectures are correct, the > > complexity > > > > > of this algorithm is O(n²). Only in the case of a selector of the > > form > > > > > "#id" we have an O(n) complexity. > > > > > However, there is another range of selectors that could be checked > > > > > with an O(n) algorithm: selectors such as "div", ".class" and > > > > > "div.class". In those cases, .is( selector ) is not needed because we > > > > > can directly check the ancestor's nodeType and className. > > > > > > Reducing the complexity of the .closest() function is particularly > > > > > important when using event delegation with the mouseover and mouseout > > > > > events: those events fire really often as the user moves his/her > > > > > mouse, and the function needs to be used twice: one to check the the > > > > > target is in the selector, and one to check that the related target > > is > > > > > in a different ancestor. > > > > > > I propose a new implementation of .closest() that is able to detect > > > > > those selectors and use them to "fast-check" ancestors. The last > > > > > parsed selector is cached to further improve the performances (I'm > > > > > just not sure where to cache the parsed selector). > > > > > > The code is available as a gist:http://gist.github.com/168158 > > > > > and can be tested here:http://www.lrbabe.com/sdoms/closest/ > > > > > > Together with the recent addition of the "context" parameter > > > > > in .closest(), it makes one of the most efficient event delegation > > > > > helper out there. > > > > > > Feedback would be much appreciated, > > > > > > Regards, > > > > > lrbabe --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
