5

I have a grid and there is a column which contains <a> anchor tag with some additional information in <data-..> tag and has a class name <class='myspeciallink'>. And in my unobtrusive JS script I select all the elements with that class name and apply live('click'). I need that to be live() because the grid gets generated in the runtime.

What happens inside the live('click') handler? I use that additional data and add a <div> to the page based on that data. Which in its turn used to generate jQuery UI dialog. It works great on my computer.

But! How could that work in real-world? Should I be bothered about possible performance implications? I feel that applying live() on more than a dozen elements instantaneously
would affect the performance. Especially with rather complicated handler like mine - it needs to get the data, parse the data, create a div, apply a dialog and etc.

Does that smell like a bad design? Could you suggest a different approach or my concerns are unfounded? Can I use some sort of a profiler tool to find the bottlenecks in my javascript?

UPD: Still nobody suggested any profiling tool. firebug and chrome dev tools are good, but maybe there is something even better?

iLemming
  • 34,477
  • 60
  • 195
  • 309

2 Answers2

4

live("click") is actually better up-front from a performance standpoint: Instead of binding an event handler to each matched element, you're applying a single event handler which waits for events to bubble up and then sees if the element that triggered the event matches the selector .live was called on.

Compare this to $('selector').click(...) which does loop over each element and bind a new event handler. live('click') has no additional overhead regardless of how many page elements match its selector. Depending on how many elements your selector matches, using .live can avoid a delay of up to a few seconds during the initial load of each page.

However, the event handler must check each event which bubbles up against its selector, to see if there is a match. This is going to add a small amount of overhead to every click event, but chances are very good that your users will not notice the difference.

user229044
  • 232,980
  • 40
  • 330
  • 338
  • Well, not necessarily, if the `click` handler stops propagation then I save the bubbling on every click, which I don't with `live`. This makes `click` better on *every* click, whereas your advantage is true just for the binding, which is once off. And the binding is a micro-micro-optimisation (as is the bubbling though I suppose). – davin May 18 '11 at 15:38
  • @davin It can be a massive savings, depending on how large the OP's grid of elements is. – user229044 May 18 '11 at 15:40
  • 1
    massive? Sounds like a bit of an overstatement, I just put together a document of 1000 tags and bound click handlers to all of them. Over 10 runs on an average laptop in chrome the time it takes to bind to all 1000 of them is 4ms. Doesn't get much quicker than that, and if that's a once off execution, you're barely optimising anything. – davin May 18 '11 at 15:56
  • @davin I have personally experienced long page delays of several seconds, ballooning to 30 seconds in Firefox with Firebug enabled, solved by replacing a `.hover` with a `.live('hover')` for highlighting table rows in a large table. This happened in the real world, on large public-facing website. You've also chosen the fastest and least-used JS implementation for your benchmark. – user229044 May 18 '11 at 17:20
2

Peter bailey also has a nice post about this: Performance difference between jQuery's .live('click', fn) and .click(fn)

Community
  • 1
  • 1
makeitmorehuman
  • 11,287
  • 3
  • 52
  • 76