Side navigation
#13349 closed bug (fixed)
Opened January 30, 2013 01:00AM UTC
Closed January 30, 2013 01:59AM UTC
Last modified February 05, 2013 03:42PM UTC
find function slower since 1.9.0, especially in chrome
| Reported by: | ktmitton@gmail.com | Owned by: | dmethvin |
|---|---|---|---|
| Priority: | high | Milestone: | 1.9.1 |
| Component: | traversing | Version: | git |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
I noticed when selecting a large array of elements (in my case 11,000+), the jQuery find function would perform much slower in 1.9.0 than in previous versions of jQuery. Looking into the code, it looks like the function was rewritten to use the jQuery.unique function, which was actually mapped to Swizzle.uniqueSort.
It turns out the actual sorting part of the function:
results.sort( sortOrder );
is where the slowdown occurs. I tested in Firefox and IE as well, and the slowdown wasn't as noticeable, but in chrome this added 5-10 seconds to the find.
I created a jsFiddle test http://jsfiddle.net/E6gPN/6/ that creates 12,000 options, runs the find, and outputs the amount of time it took to execute the find.
Attachments (0)
Change History (6)
Changed January 30, 2013 01:24AM UTC by comment:1
| status: | new → open |
|---|
Changed January 30, 2013 01:31AM UTC by comment:2
Replying to [comment:1 dmethvin]:
1) In what kind of situation do you have 11,000 DOM elements? 2) Looks like it's unnecessarily going through a unique sort in .find() since for that simple case the results will already be sorted.1) I know it sounds ridiculous, but I actually do have a few select boxes that are populated with that many options, and I'm not permitted to change that.
2) Yeah, that's what I found. If I had to guess, the unique function call probably just seemed like a nice way to trim down the original code in the function, and the sort probably seemed negligible to the person who rewrote find, and like you said doesn't really change anything.
Changed January 30, 2013 01:45AM UTC by comment:3
| component: | unfiled → traversing |
|---|---|
| milestone: | None → 1.9.1 |
| owner: | → dmethvin |
| priority: | undecided → high |
| status: | open → assigned |
Changed January 30, 2013 01:59AM UTC by comment:4
| resolution: | → fixed |
|---|---|
| status: | assigned → closed |
Fix #13349. No need to sort simple .find() cases.
Changeset: 1bbe2b1ded24edf7bf7b18512aff4148591803da
Changed January 30, 2013 02:00AM UTC by comment:5
Fix #13349. No need to sort simple .find() cases.
Changeset: a5c33fe1f7872a20267ff69905561c8cc55fe3c1
Changed February 05, 2013 03:42PM UTC by comment:6
Excellent site - do keep up the good work.
1) In what kind of situation do you have 11,000 DOM elements?
2) Looks like it's unnecessarily going through a unique sort in
.find()since for that simple case the results will already be sorted.