Actually it's not really efficient for us to do that - since we would need to expose literally everything and in the end we would end up with the same result as running it through the simple minifier. As it turns out though the simple minifier is quite good - giving us a 13% improvement over YUI Min.

That's a good explanation, but its not actually that jQuery automatically binds events to the newly inserted elements, its that it takes advantage of Javascript's event bubbling to match the selector at the highest level it can.

Basically, if you had HTML like this:

    <div>
        <p>
            <span>Hello World</span>
        <p>
    </div>

and the user clicks on the span, Javascript will raise a click event not only for the span but for each of its parents (p, div, body and html).

jQuery's live events take advantage of this by "trapping" the click event (or blur, focus, etc) at the highest level. This leads to 2 distinct advantages:

1) Elements inserted into a page after the script is initialized don't need to have events bound to them. (this is what defen was referencing)

2) You don't have to bind a callback to every single element.

The second can pay dividends even if there is no dynamically inserted content. For instance, lets say you have a table with 1000 cells and you want to make them editable when the user clicks on them.

Traditionally, you would do something like this:

    $('td').click(function () { makeCellEditable(this); } );

Although this would work, binding 1000 callbacks, one to each td element, will seriously impact browser performance.

With live events the syntax is very similar:

    $('td').live('click', function () { makeCellEditable(this); } );

The difference is we've only bound 1 event, so the browser's performance will not be adversely affected.

Hope that helps.

Good catch, thanks.

Actually, we did reduce the complexity to a constant: Went from n^2 to just n: http://ejohn.org/blog/function-call-profiling/

The 4x number was wall-clock time for the particular tests - so obviously your mileage may vary. In fact, the more complicated your case the better your eventual gains will be.

This is a very standard way libraries have been presenting their speed comparison for quite awhile now. You can look at the individual slivers to get a rough estimate of the size difference, and overall cross browser comparison, and see which browsers are the slowest.

It's a very good visualization, letting one compare the same browser across two version of jquery, an aggregate of browsers across both versions, and the speed of individual browsers against each other on the same version, and individual speeds across the different versions. It's very data packed.