perf: speed up non-modules CSS parsing - #21511
Conversation
Profiling popular CSS frameworks (Bootstrap, Bulma, Foundation, Pico, Tachyons, Tailwind) showed the token-stream plumbing (next/consume/discard) among the hottest parse costs. The "peek, decide, advance" sites re-invoked next() from consume()/discard() purely to re-derive the already-cached token. Add TokenStream#advance(), a cursor bump that skips that redundant re-check, and use it at the guaranteed-non-EOF sites: the whitespace-discard loops, the declaration colon, block-contents whitespace/semicolon, skipped value leaves, and the leaf component-value path (the bulk of nodes on a large stylesheet). Output is byte-identical over 662k parsed nodes across the framework corpus plus edge cases; a paired interleaved benchmark shows ~1-2% faster parsing.
In non-modules parsing the selector prelude is skipped (`selectorPrelude`),
yet consumeAQualifiedRule still built a store node for every prelude token —
class, id, combinator, pseudo — only to discard all but url()/function nodes.
Add a pre-materialization skip mirroring consumeAListOfComponentValues: leaf
selector tokens are advanced past without allocating a node, and the
`--foo: {` custom-property disambiguation reads the first two tokens' type and
start directly instead of from materialized nodes. Functions and `(`/`[`
blocks (which may hold a url) are still materialized.
Output is byte-identical (skip and no-skip fingerprints; all CSS tests pass);
the real non-modules path parses ~8-18% faster on selector-heavy frameworks.
In non-modules mode selector preludes are usually empty, so avoid taking a scratch list from the pool and sealing it on every rule; allocate the prelude list only on the first pushed node. `_makeContainer` already zeroes the rule's list length, so an unsealed (null) prelude reads as empty in the walk.
In non-modules mode value/prelude leaf tokens are dropped, so most container seals hand `_setValue` an empty list. `_makeContainer` already leaves the node's list length at 0, so an empty seal can skip the flat-buffer bounds check, copy loop, and start/length writes and just recycle the scratch array.
🦋 Changeset detectedLatest commit: c010239 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
This PR is packaged and the instant preview is available (7641790). Install it locally:
npm i -D webpack@https://pkg.pr.new/webpack@7641790
yarn add -D webpack@https://pkg.pr.new/webpack@7641790
pnpm add -D webpack@https://pkg.pr.new/webpack@7641790 |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #21511 +/- ##
==========================================
+ Coverage 93.57% 93.59% +0.02%
==========================================
Files 619 619
Lines 73232 73678 +446
Branches 21105 21258 +153
==========================================
+ Hits 68526 68960 +434
- Misses 4706 4718 +12
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Merging this PR will degrade performance by 30.6%
|
| Mode | Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|---|
| ❌ | Memory | benchmark "devtool-eval", scenario '{"name":"mode-development-rebuild","mode":"development","watch":true}' |
132.7 KB | 342.1 KB | -61.22% |
| ❌ | Memory | benchmark "context-esm", scenario '{"name":"mode-production","mode":"production"}' |
7.6 MB | 11.3 MB | -32.97% |
| ❌ | Memory | benchmark "future-defaults", scenario '{"name":"mode-production","mode":"production"}' |
6.9 MB | 9.6 MB | -27.78% |
| ⚡ | Memory | benchmark "asset-modules-resource", scenario '{"name":"mode-development","mode":"development"}' |
2.2 MB | 1.8 MB | +23.58% |
Tip
Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.
Comparing claude/css-framework-profiling-7zkpqr (c010239) with main (d6afbe0)
Types CoverageCoverage after merging claude/css-framework-profiling-7zkpqr into main will be
Coverage Report |
|
The CodSpeed
The changes here strictly reduce CSS-parser allocations (lazy prelude, empty-list seal fast path) and are behaviour-preserving (byte-identical AST verified via differential fingerprint), so a real memory increase — especially in a build that parses no CSS — isn't possible. Nothing to fix in code. Generated by Claude Code |
Summary
Profiling the CSS parser against popular framework CSS (Tailwind, Bootstrap, Bulma, …) surfaced avoidable work on the real non-modules parse path (
SKIP_NON_MODULES, the mode most builds hit). This lands four compounding, behavior-preserving optimizations inlib/css/syntax.js: (1) anadvance()helper that skips the redundantnext()re-check at guaranteed-non-EOF peek→advance sites; (2) in non-modules mode, dropping selector-prelude leaf tokens without materializing a node; (3) allocating a qualified rule's prelude list lazily so empty preludes cost nothing; (4) a fast path in_setValuethat skips the flat-buffer seal for empty lists. Cumulatively ~22–27% faster on the non-modules parse path over the framework corpus (paired benchmark, sign test 60/60), with no change to the produced AST.What kind of change does this PR introduce?
perf
Did you add tests for your changes?
No new tests — the changes are behavior-preserving and covered by the existing 157 CSS tests (all pass). Correctness was verified out-of-band with a differential AST fingerprint (byte-identical output in both the non-modules skip path and the full no-skip
parseAStylesheettree) over the framework corpus plus hand-picked edge cases.Does this PR introduce a breaking change?
No.
If relevant, what needs to be documented once your changes are merged or what have you already documented?
n/a — internal parser performance only; no public API or config change.
Use of AI
AI (Claude) was used to profile the CSS parser against a corpus of popular framework CSS, identify the hot paths, draft the optimizations, and build the differential-fingerprint and paired-benchmark harnesses used to validate byte-identical output and measure each change. All changes were reviewed and each was kept only after confirming identical AST fingerprints and a clear paired-benchmark win; candidate changes that regressed or altered output (e.g. skipping simple-block leaves) were discarded.
Generated by Claude Code