Latest Results
perf(core): share file counter dependency lists by interned content
The file counter's reverse index stored, per path, the set of dependency
ids that reference it. A dependency records its file list at every path it
mentions, so the same id list was materialized once per referenced path,
and every add inserted the id into each of those sets again.
Store the dependency side by the interned list instead: the ids recorded
with one exact list live in a single set, and each path keeps handles to
the lists that mention it. Equal lists already share an interned handle,
so equal content is stored once, adding or removing a dependency touches a
single set no matter how many paths its list mentions, and a path's
dependencies stay the union of the lists that mention it. Module resources
keep their per-path sets.
A path that belongs to very many distinct lists - resolver candidates are
probed by many different factorize results - switches its references from
a small dense vector to a set above a threshold. Dissolving one of those
lists removes one reference per path it mentions, and scanning a long
dense vector for every removal degrades the make phase into quadratic
work; the set removes in constant time.
InternedPathList now hashes by its interned content fold so it can key the
group map, and FactorizeInfo exposes its interned lists to the call sites
that add or remove dependency files.seal/am13b-shared-dependency-lists Latest Branches
+3%
codex/allocative-rspack-skill 0%
-3%
© 2026 CodSpeed Technology