eq() performance improvement and negative indices

[ricardobeat]

Currently $(...).eq(x) is much slower than $( $(..)[x] ). This patch improves performance by pushing the single element into a new object via pushStack.

[ricardobeat]

patch

[ricardobeat]

Notice that the 'selector' string will now read ".eq(1)" instead of ".slice(1,2)", hope that's not a problem.

[ricardobeat]

patch with support for negative indexes

[ricardobeat]

Added support for negative indexes to comply with the changes in get().

 http://groups.google.com/group/jquery-dev/browse_thread/thread/432e256106530123?hl=en

[ricardobeat]

Oh, could someone change the ticket description to include this enhancement? Or should I have put this in a separate ticket?

[dmethvin]

Dup #4731 has an alternate patch for negative indices.

[Christian Meixner <christian.meixner@…>]

.eq(i) still is much slower than $($(..)[i])

see jsperf:  http://jsperf.com/jquery-eq

Why not just return $($(..)[i]) in .eq()?

return $(collection[i < 0 ? collection.length - i: i ]);

The current implementation of .eq() can not be recommended for loops.

[ajpiano]

That jsPerf shows jQuery 1.6.1 - I made another that shows 1.6.1 and 1.8.2 side by side, where the fundamental problem persists.  http://jsperf.com/jq-eq-index-vs-jq-jqobj-index

We can't return jQuery( jQuery(...)[i] ) because it breaks the stack, behaviour of .end(), etc. but I do agree that it would be good to get to the bottom of why it's so dramatically slower here, though I suspect that it can be chalked up to the fact that the various operations required to retain the expected API behaviour bring with them some inherent overhead

[gibson042]

2.5x-8x speedup!  http://jsperf.com/jq-eq-index-vs-jq-jqobj-index/2  https://github.com/jquery/jquery/pull/1000

[Richard Gibson]

Fix #4262: faster .eq(), closes gh-1000.

Changeset: b5084b4bf29a2e517b90d5e7d82ed17c94a71d94