Bug Tracker

#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 anonymous comment:1

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

Changed May 02, 2013 01:18PM UTC by anonymous 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 dmethvin 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 albertcasademont@gmail.com 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 dmethvin 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.