Bug Tracker

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#13849 closed bug (notabug)

Weird performance issue in jQuery.find

Reported by: [email protected] Owned by:
Priority: undecided Milestone: None
Component: unfiled Version: 2.0.0
Keywords: Cc:
Blocked by: Blocking:


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!

Change History (5)

comment:1 Changed 10 years ago by anonymous

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

comment:2 Changed 10 years ago by anonymous

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.

comment:3 Changed 10 years ago by dmethvin

Resolution: notabug
Status: newclosed

Most importantly, this is not a bug. It's better to discuss things like this on the forum or StackOverflow.

comment:4 Changed 10 years ago by [email protected]

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.

comment:5 Changed 10 years ago by dmethvin

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.

Note: See TracTickets for help on using tickets.