Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#8654 closed defect (fixed)

Speed discrepencies in dojo.query

Reported by: dante Owned by: alex
Priority: high Milestone: 1.3
Component: Query Version: 1.3.0b1
Keywords: Cc: dante
Blocked By: Blocking:

Description

Running some slickspeed tests I noticed what could be a potential regression in dojo.query selector speeds. It seems to choke on all variations of p:nth-child(), pushing test results well into the red. The speeds are balanced until the test reaches those selectors. Attached are totals from a number of browsers testing the original and a modified version of slickspeed.

Attachments (1)

slick.txt (1017 bytes) - added by dante 10 years ago.
my results, pseudo-csv format

Download all attachments as: .zip

Change History (4)

Changed 10 years ago by dante

Attachment: slick.txt added

my results, pseudo-csv format

comment:1 Changed 10 years ago by alex

Resolution: fixed
Status: newclosed

(In [16870]) fixes a typo in getNodeIndex which caused node indexes to be lost, dropping our speed on nth-child queries. Also significantly improves peformance on ":not" pseudos by specifying ignores in the test generator. Fixes #8654. !strict

comment:2 Changed 10 years ago by alex

(In [16871]) even more speedups on the DOM branch. Was doing some dumb stuff for ID and tag-only queries which this checkin fixes. Also, attempt to preserve zip-killing across groups. Tests show us to be ~30% faster than sizzle on IE 6. QSA branch still faster nearly everywhere, but by variable amounts depending on the engine (15-50%). Refs #8654. !strict

comment:3 Changed 10 years ago by bill

Component: CoreQuery
Note: See TracTickets for help on using tickets.