-
-
Notifications
You must be signed in to change notification settings - Fork 52
Performance
The benchmark guide contains the query charts, test commands, and measurement methods. The performance guide explains the CPU profiles and compiler changes.
Cold queries run a selector first on a fresh document. Warm queries repeat it.
The recorded first-match chart covers 12 queries that return an element.
It shows cold speedups of 1.3–13.8× and warm speedups of 1.8–12.9× against @asamuzakjp/dom-selector through jsdom.
These results apply to the listed queries and test HTML.
The generated HTML models React/Next.js components, Tailwind-style classes, and Testing Library test IDs.
The benchmark uses these HTML patterns without running the frameworks or libraries.
Each engine gets a separate document.
Document creation and explicit NWSAPI setup happen before the cold timer starts.
The first jsdom query includes setup performed inside its public method.
Each chart has stacked lines for the two engines. Green and teal identify NWSAPI. Purple and pink identify the other engine. Each line connects cold and warm markers on a logarithmic time scale. Further left means less time. Each scale step increases time by a factor of ten. The text below each pair gives the timing comparison. Package versions and API details appear in separate, muted note lines.
See the measurement method and raw samples.
For early class matches, the engine checks a limited group of elements before requesting a full class collection. It can reuse candidates from that group after checking for document changes. The cold-query study records the measurements and profiles.
A later change removed repeated document-property reads from the reuse path. Four early class queries took 24–45% less time than the build before the cold fix. See the warm-cache follow-up.
The compiler also saves first-match plans and limits sibling counting to the direction needed for a single-element check.
Install the optional jsdom peer dependency to use the compiler command.
The compiler guide explains how to inspect generated functions with nwsapi compile.
The all-results suite tests component, documentation, and utility-class pages.
Its recorded comparison has lower NWSAPI median times for all 36 queries, with 32 at least 2× faster.
It compares NWSAPI v2.2.27, NWSAPI v2.3.0-prerelease, and @asamuzakjp/dom-selector v8.3.2 through jsdom v30.0.1.
Chromium checks the returned elements and their order before timing starts.
The charts use thin bars on a linear scale. Shorter bars mean less time. See the all-results comparison. The guide also retains the earlier warm-only first-match table in a collapsed section.
The timing runners now use mitata.
Cold samples receive fresh state for each invocation, with setup outside the timer.
Warm samples reuse the document.
New result files record the mitata version and the all-results batch samples.
The published measurements above predate this migration.
The recorded machine was an Apple M3 Max with Node.js v26.5.0.
The tests call NWSAPI directly and call the other engine through public jsdom methods.
Those methods include additional integration work.
Small timing differences can change with machine load.
Use the saved source hashes, versions, and samples to identify each comparison.
The original performance review records the earlier gaps and proposed targets. It is a historical plan. Use the benchmark guide for later measurements.