perf: reduce props proxy closure allocations - #3391

Summary

Replace per-instance proxy target closures in mergeProps and splitProps with private-symbol data read by shared handlers. Proxy counts and public types stay unchanged. Local benchmarks showed 19–46% lower median creation time across four runs.

What changes?

The proxy handlers are already shared today. However, each output proxy's target contains three newly created methods (get, has, keys) closing over that instance's data. This change stores the data on the target and moves that work into shared functions.

Simplified target construction:

// Before: fresh methods closing over sources for every instance.
new Proxy({
  get(key) { return lookup(sources, key); }
  // Fresh has() and keys() methods too.
}, propTraps);

// After: instance data only; shared handlers read target[sourcesKey].
new Proxy({ [sourcesKey]: sources }, mergeHandler);

For 10,000 merge instances, both versions allocate 10,000 proxies and targets, but the new version avoids 30,000 instance-specific methods. Reads also skip the forwarding call from handler to target method. splitProps uses the same approach for source, selected keys, and remainder state.

Private symbols prevent Object.defineProperty on names such as source or sources from overwriting internal state. The regression test covers that isolation, symbol visibility, and live reads after store updates.

Performance

Local comparison on Apple M4 Pro, Node 25.9.0 / V8 14.1, Vitest 4.1.10 with jsdom. Four fresh processes, alternating implementation order. Each operation handles 10,000 retained instances backed by distinct real stores; source setup is outside timing. Reads access four fields per instance.

Times are milliseconds per batch, reported as the median of four per-run means:

Creation improved in every paired run, but reductions varied substantially: 14–40% for merge, 13–54% for split, and 13–56% for the chain. Read results were less consistent, including one noisy merge-read result (8.36 ms, ±23% RME) that did not recur. These are exploratory local measurements, not browser-wide performance guarantees; allocation, GC, and engine optimization effects have not been separated.

The PR includes the six retained-instance benchmarks for reproducing the workload across revisions; the local comparison harness and saved results are not included.

How did you test this change?

• pnpm run build
• pnpm test — 492 runtime tests passed, plus type, Babel preset, and import checks.
• pnpm --dir packages/solid exec vitest bench test/props-retained.bench.ts --run — all 6 cases passed.