solidjs / solid / 36232586916

74%

main: 89%

push

github

fix(signals): store enumerators no longer materialize a presence node per key (#3664) (#3668)

A computation that enumerates a store object — Object.keys, for...in,
spread, Object.entries, JSON.stringify — takes the getOwnPropertyDescriptor
trap once per key right after ownKeys. 765a65665 (rc.9) made that trap a
presence read so a LONE descriptor inspection re-runs for an optimistic add
or delete, which was right for that reader, but every enumerator then
birthed one presence node per key of the object (signal + node extension +
unobserved closure, ~640 B and a graph node each) on top of the key-set
node ownKeys had already subscribed it to. A 30-field row's Object.keys
reader went from 2.0 KB to 20 KB, spread from 10.9 KB to 28.9 KB, creation
time ~1.5-2x; the key-set node bumps on every membership change, committed
or optimistic, so the per-key nodes could never tell an enumerator anything.

The descriptor trap now skips the presence read when the observer already
holds the target's key-set node in the CURRENT pass — the mirror of link()'s
O(1) repeat-touch check (newest subscriber link is this observer's and, in
a recompute, carries this pass's dep generation), so a stale link from a
previous pass never suppresses a subscription and no dep list is scanned.
A lone descriptor read keeps its per-key presence node; the structural
oracle's descriptor cells stay rules.

Tests: tests/store/enumerator-presence-nodes.test.ts pins zero presence
nodes and one key-set subscription per enumerator (memo and effect, 1k rows
x 30 fields), add/delete re-runs committed and optimistic, the lone
descriptor reader's single node and its optimistic add/delete re-runs, the
stale-link and same-pass $TRACK cases. Bench: tests/store/enumerate.bench.ts
(leafRead reference, Object.keys, for...in, spread over 1k rows x 30 fields)
— Object.keys 23.6 -> 11.1 ms, for...in 22.4 -> 11.5 ms, spread 36.0 ->
23.7 ms locally. Size: +createStore 17,096 -> 17,135 B brotli (limit
17,150), ... (continued)

625 of 914 branches covered (68.38%)

Branch coverage included in aggregate %.

922 of 1183 relevant lines covered (77.94%)

27.05 hits per line