Side navigation
#4262 closed enhancement (fixed)
Opened February 26, 2009 09:58PM UTC
Closed October 20, 2012 02:34AM UTC
eq() performance improvement and negative indices
| Reported by: | ricardobeat | Owned by: | gibson042 |
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | core | Version: | 1.3.2 |
| Keywords: | eq, performance | Cc: | ricardobeat |
| Blocked by: | Blocking: |
Description
Currently $(...).eq(x) is much slower than $( $(..)[x] ). This patch improves performance by pushing the single element into a new object via pushStack.
Attachments (2)
Change History (10)
Changed February 26, 2009 09:59PM UTC by comment:1
Changed February 28, 2009 07:50PM UTC by comment:2
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
Changed February 28, 2009 07:51PM UTC by comment:3
Oh, could someone change the ticket description to include this enhancement? Or should I have put this in a separate ticket?
Changed June 08, 2009 01:02AM UTC by comment:4
| summary: | eq() performance improvement → eq() performance improvement and negative indices |
|---|
Dup #4731 has an alternate patch for negative indices.
Changed September 14, 2009 06:51PM UTC by comment:5
| cc: | → ricardobeat |
|---|---|
| owner: | → flesler |
Changed November 11, 2009 06:10PM UTC by comment:6
| resolution: | → fixed |
|---|---|
| status: | new → closed |
Changed October 16, 2012 07:54AM UTC by comment:7
.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.
Changed October 19, 2012 01:33AM UTC by comment:8
| milestone: | 1.4 |
|---|---|
| resolution: | fixed |
| status: | closed → reopened |
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
Changed October 19, 2012 09:12PM UTC by comment:9
| _comment0: | http://jsperf.com/jq-eq-index-vs-jq-jqobj-index/2 \ https://github.com/jquery/jquery/pull/1000 → 1350681334663628 |
|---|---|
| owner: | flesler → gibson042 |
| status: | reopened → assigned |
Changed October 20, 2012 02:34AM UTC by comment:10
| resolution: | → fixed |
|---|---|
| status: | assigned → closed |
Fix #4262: faster .eq(), closes gh-1000.
Changeset: b5084b4bf29a2e517b90d5e7d82ed17c94a71d94
Notice that the 'selector' string will now read ".eq(1)" instead of ".slice(1,2)", hope that's not a problem.