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 -~----------~----~----~----~------~----~------~--~---
