Bug Tracker

Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#13849 closed bug (notabug)

Weird performance issue in jQuery.find

Reported by: albertcasademont@… 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 8 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 8 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 8 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 8 years ago by albertcasademont@…

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 8 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.