Side navigation
#13849 closed bug (notabug)
Opened May 02, 2013 08:59AM UTC
Closed May 02, 2013 01:26PM UTC
Last modified May 02, 2013 03:19PM UTC
Weird performance issue in jQuery.find
Reported by: | albertcasademont@gmail.com | Owned by: | |
---|---|---|---|
Priority: | undecided | Milestone: | None |
Component: | unfiled | Version: | 2.0.0 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
See http://jsperf.com/jquery-find-vs-context-sel/38
Cases 1 and 2 should be almost the same. In fact, I would expect Case 2 to be faster than one as the jQuery object is already created, but it is 92% slower. Same thing between cases 3 and 4.
The weirdest thing is that a complete $('article > ins') selector is faster than a cached selector + find.
Is this normal? Thanks!
Attachments (0)
Change History (5)
Changed May 02, 2013 09:09AM UTC by comment:1
Changed May 02, 2013 01:18PM UTC by comment:2
The two case are not the same at all. There is really big difference.
Case 1 contains only a single DOM-Node to search.
Case 2 contains all the article-nodes of your DOM. There are ten article tags, so case 2 does ten times the work of case 1.
Changed May 02, 2013 01:26PM UTC by comment:3
resolution: | → notabug |
---|---|
status: | new → closed |
Most importantly, this is not a bug. It's better to discuss things like this on the forum or StackOverflow.
Changed May 02, 2013 03:10PM UTC by comment:4
First, sorry for my stupidity, this was not the correct case, as you said, there were 10 articles not 1. I've updated the initial data. Now there is only one article and case 2 is 50% slower.
Second, IMHO a possible performance bottleneck should be considered a bug.
Changed May 02, 2013 03:19PM UTC by comment:5
Post on the forum proving it's a bottleneck. That is, in a real page, the program is spending a significant part of its time on a selector like this. The profilers in modern browsers can be a help in that effort, try the one in Chrome or IE10. Even your slowest case there only takes about 1/8th of a millisecond to run, I don't see how that could be a bottleneck.
I ran the test with Firefox, Chrome, Chrome in a Nexus 4 and Safari in an iPhone 4 and the issue remains, so it seems it has nothing to do with some browser specific hack/trick/bug