views:

506

answers:

3

I have a big content slideshow kinda page that I'm making that is starting to use a lot of event triggers. Also about half of them use the livequery plugin.

Will I see speed increases by unloading these events between slides so only the active slide has bound events?

Also is the native livequery significantly faster then the livequery plugin?(cause it's certainly less functional)

Also would something like this: http://dev.jquery.com/attachment/ticket/2698/unload.js

unbind livequery events as well?

I really just need to know how long it takes to unload/load an event listener vs how many cycles they are really eating up if I leave them running. Also any information on live events would be awesome.

+7  A: 

I need more details to offer actual code, but you might want to look into Event Delegation:

Event delegation refers to the use of a single event listener on a parent object to listen for events happening on its children (or deeper descendants). Event delegation allows developers to be sparse in their application of event listeners while still reacting to events as they happen on highly specific targets. This proves to be a key strategy for maintaining high performance in event-rich web projects, where the creation of hundreds of event listeners can quickly degrade performance.

A quick, basic example:

Say you have a DIV with images, like this:

<div id="container">
    <img src="happy.jpg">
    <img src="sad.jpg">
    <img src="laugh.jpg">
    <img src="boring.jpg">
</div>

But instead of 4 images, you have 100, or 200. You want to bind a click event to images so that X action is performed when the user clicks on it. Most people's first code might look like this:

$('#container img').click(function() {
    performAction(this);
});

This is going to bind a crapload of event handlers that will bog down the performance of your page. With Event Delegation, you can do something like this:

$('#container').click(function(e) {
    if($(e.target)[0].nodeName.toUpperCase() == 'IMG') {
        performAction(e.target);
    }
});

This will only bind 1 event to the actual container, you can then figure out what was clicked by using the event's target property and delegate accordingly. This is still kind of a pain, though, and you can actually get this significant performance improvement without doing all this by using jQuery's live function:

$('#container img').live('click', function() {
     performAction(this);
});

Hope this helps.

Paolo Bergantino
That is very interesting and good to know, but not exactly the answer to my questions.What I really want to know is if leaving say, 15-20 event handlers running is faster then loading 5+ handlers and unloading 5+ handlers between slides.
thirsty93
Well, what I am saying is that you can just leave the same 5 handlers running and delegate, so there is no need to keep binding and unbinding.
Paolo Bergantino
@thirsty: if you're looking for performance, this is a very good answer. Paolo is saying you'd have ONE handler vs 15-20.
Crescent Fresh
never thought of that - thanks for the insight
Slee
+3  A: 

If by "native liveQuery" you mean live(), then yes, live() is significantly faster than liveQuery(). The latter uses setInterval to periodically query the entire document tree for new elements while the former uses event delegation.

Event delegation wins handsdown. In a nutshell, live() will have one handler on the document per event type registered (eg, click), no matter how many selectors you call live() with.

As for your other question, it sounds like you are binding to each slide's elements and want to know if unbinding and binding again is performant? I would say WRT memory, yes. WRT CPU cycles, no.

To be clear, with the liveQuery() approach CPU will never sleep.

Crescent Fresh
A: 

For what it's worth. We just ran some tests on this matter. We created a page with a div containing a number of divs, each of which needed to have an onclick handler display an alert dialog with showing their id.

In one case we used DOM Level 0 event registration and defined the event handler for each directly in the html for each: onclick="_do_click(this);". In the other case, we used DOM level 2 event propagation and defined a single event handler on the containing div.

What we found was, at 100,000 contained divs, there was negligible difference in the load time on FireFox. It took a long time period. In Safari, we found that the DOM level 0 took twice the time off the DOM level 2, but was still four times faster than either FireFox case.

So, yes, it does result in better performance, but it seems like you really have to try to create a noticeable penalty.