chore(perf): improve caching in SplitChunksPlugin - #21529

🦋 Changeset detected

Latest commit: 5ad2572

The changes in this PR will be included in the next version bump.

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

PR Summary

Medium Risk
Touches core split-chunks graph logic where signature false negatives could change chunk splits; mitigated by existing behavior paths and a new high-chunk stats snapshot test.

Overview
Speeds up SplitChunksPlugin during chunk-combination work (reported ~32% faster SplitChunks time and far fewer isSubset calls on large graphs).

When finding subset chunk sets in getCombinations, each candidate set now has a 64-bit membership signature (two Uint32 words per set, keyed by a dense per-chunk bit index). Candidates whose signature has bits the superset lacks are skipped before calling isSubset on the underlying Sets.

Caching changes: unnamed chunksInfoMap keys (cacheGroup + chunk set) are built once per pair via getUnnamedKey instead of per module. Per-module chunk combinations drop memoize() closures in favor of lazy combsCache / combsByUsedExportsCache filled on first use by a cache group.

Adds a split-chunks-many-chunks stats fixture (70 async routes + layered shared deps) with a Jest snapshot to lock split output under heavy splitChunks settings.

^{Reviewed by Cursor Bugbot for commit 5ad2572. Bugbot is set up for automated code reviews on this repo. Configure here.}

This PR is packaged and the instant preview is available (bcb1abd).

Install it locally:

• npm

npm i -D webpack@https://pkg.pr.new/webpack@bcb1abd

• yarn

yarn add -D webpack@https://pkg.pr.new/webpack@bcb1abd

• pnpm

pnpm add -D webpack@https://pkg.pr.new/webpack@bcb1abd

Types Coverage

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.79%. Comparing base (d6afbe0) to head (5ad2572).
⚠️ Report is 16 commits behind head on main.

@@            Coverage Diff             @@
##             main   #21529      +/-   ##
==========================================
+ Coverage   93.59%   93.79%   +0.20%     
==========================================
  Files         619      620       +1     
  Lines       73650    73315     -335     
  Branches    21244    21192      -52     
==========================================
- Hits        68933    68769     -164     
+ Misses       4717     4546     -171     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

Merging this PR will degrade performance by 22.94%

⚡ 1 improved benchmark
❌ 1 regressed benchmark
✅ 214 untouched benchmarks

Performance Changes

_{Comparing splitchunkspluginperf (5ad2572) with main (59566fc)}

@codspeedbot is this regression relevant to the changes, I don't think so

@codspeedbot is this regression relevant to the changes, I don't think so

You're right — this regression does not look attributable to the SplitChunksPlugin changes. Here's what I found:

The flagged benchmark doesn't exercise the changed code. The regressed benchmark is devtool-eval (mode-development-rebuild), whose config is a single-entry build with devtool: "eval" and no optimization.splitChunks configuration. With a single entry and no async/shared chunk sets, the new subset-search machinery (per-set 64-bit signatures, getUnnamedKey caching, the combsCache/combsByUsedExportsCache locals) operates over a trivial chunk set and allocates negligible memory. A 1.3 MB → 3.1 MB peak-memory swing (~1.8 MB) can't plausibly come from a couple of tiny Uint32Arrays on a build that has essentially nothing to split.

The paired result points to measurement noise, not the change. The only other moved benchmark is the improvement, asset-modules-resource (mode-development-rebuild), which is also a single-entry build with no splitChunks config. Two unrelated single-entry, Memory-mode, watch-rebuild benchmarks swinging in opposite directions (−58% / +42%) is the classic signature of GC-timing / peak-memory jitter in rebuild scenarios, not a systematic effect of the SplitChunks logic.

Scope check. I reviewed lib/optimize/SplitChunksPlugin.js: the new signature maps, unnamedKeyCache, and per-module combination caches are all declared inside the optimizeChunks tap (and the per-module loop) — they're transient per run, not persisted across compilations, so they don't accumulate across watch rebuilds.

So the 22.94% headline is being driven by this single unrelated Memory-rebuild benchmark. I'd treat it as noise and acknowledge it rather than chase it as a real regression from this PR. The benchmarks that would reflect your change (e.g. many-chunks-*) are untouched.

One caveat worth flagging: CodSpeed also reports that several benchmarks ran across different runtime environments (Intel vs AMD CPUs) between base and head. The devtool-eval Memory benchmark itself isn't in the affected list, so its comparison is on matching runners — but it's another reason to be cautious reading small Memory deltas on this run.

_{Was this response helpful? React with 👍 or 👎 to help us improve CodSpeedBot.}