I was also wondering what kind of selectors jQuery.expr was used for. >From my own experience, there is a clear benefit in .closest because I almost exclusively use selectors of the form "div" or ".class". But I just realized that .hasClass() would also benefit from this optimization with its current implementation, and I use .hasClass() a lot!
On Aug 18, 1:00 am, lrbabe <lrb...@gmail.com> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
