2.0.0 | slow and steady wins the race

[mizulu]

Describe the bug

updating store ~4000 times, 2 keys at a time
takes ~3s to complete

 import { createStore, flush } from "solid-js"

 const COUNT = 4000
  const [store, setStore] = createStore({})
  const start = performance.now()

  for (
    let i = 1; i < COUNT; i++
  ) {
    setStore(store => {
      store[i - 1] = false
      store[i] = true
    })
    flush()
  }

  console.log(
    (performance.now() - start).toFixed(3),
    "ms"
  )

hot path

similar code in solid 1.x takes few ms for 100,000 updates
https://s.olid.uk/id/EGa-sTlDQuyeVbKU8nv3Sw

import { render } from 'solid-js/web';
import { createSignal, createEffect } from 'solid-js';

import { produce, createStore } from "solid-js/store"



const COUNT = 100000


const [store, setStore] = createStore({})


const start = performance.now()
for (
  let i = 1; i < COUNT; i++
) {
  queueMicrotask(() => {
    setStore(
      produce(store => {
        store[i - 1] = false
        store[i] = true
      })
    );

  })


}


console.log((performance.now() - start).toFixed(3) , "ms")

Your Example Website or App

https://s.olid.uk/id/r3tCfj0USguLi24fIhUXbg

Steps to Reproduce the Bug or Issue

see repro

Expected behavior

speed

Screenshots or Videos

No response

Platform

.

Additional context

No response

[mizulu]

function cloneRaw(source, t) {
  // Descriptor-preserving shallow clone (R29: installed getters stay live;
  // ruled 2026-08-17: frozen sources clone unfrozen — theirs stays frozen).
  // Data descriptors normalize to writable+configurable (the clone is OURS to
  // mutate — R51's "source-non-configurable is writable through the store");
  // enumerability and accessors are preserved. The scan doubles as the
  // accessor-flag detector (free — we're enumerating descriptors anyway).
  const descs = Object.getOwnPropertyDescriptors(source);
  for (const key of Reflect.ownKeys(descs)) {
    const d = descs[key];
    if (key === "length" && Array.isArray(source)) continue;
    d.configurable = true;
    if (!d.get && !d.set) d.writable = true;
    else if (t) t.a = true;
  }
  return Array.isArray(source)
    ? Object.defineProperties([], descs)
    : Object.create(Object.getPrototypeOf(source), descs);
}
function ensurePB(target) {
  let pb = target.pb;
  if (pb === null) {
    pb = target.pb = cloneRaw(target.v, target);
    // Optimistic families: seed USER drafts from the OPTIMISTIC VIEW
    // (committed + active node overrides), so follow-up writes compose on
    // optimism instead of clobbering from base (#2951's compose half).
    // AUTHORITATIVE drafts (projection recompute / write-override landings)
    // seed from committed truth — seeding overrides there would fold a lane
    // value into the committed home ("authority wins at reveal" would break).
    if (target.fam?.opt && !projectionWriteActive && !getWriteOverride()) {
      const nodes = target.n;
      if (nodes !== null) {
        for (const key of Reflect.ownKeys(nodes)) {
          const node = nodes[key];
          if (hasActiveOverride(node)) pb[key] = unwrapOverride(node._overrideValue);
        }
      }
      const has = target.h;
      if (has !== null) {
        for (const key of Reflect.ownKeys(has)) {
          const node = has[key];
          if (hasActiveOverride(node) && !unwrapOverride(node._overrideValue)) delete pb[key];
        }
      }
    }
    ownedRaw.add(pb);
    (target.fam?.map ?? storeNextLookup).set(pb, target);
    queueFold(target);
  }
  return pb;
}

[ryansolid]

Fixed on next by the prototype-overlay pending-backing work:

• a1b8958 — plain-object setter drafts now open as prototype overlays of the committed backing: O(written) per flush instead of O(container) clones. The issue's repro drops from ~350ms to ~5ms.
• 45c831f — overlay state resets on setter-return adoption (audit follow-up), with targeted regression tests (tests/store/overlay.test.ts).
• c38bc24 / follow-ups — pre-shaped proxy targets so the new fields never tip V8 into dictionary mode, plus a tier-1 selection-map bench pinning the write-path scaling.

Ships in the next 2.0 release cut from next.

[mizulu]

After the fix

drastic improvement confirmed

For Count 100,000 @ 450ms
4000 @ 18ms

https://s.olid.uk/id/ttDVKB0dQQmA-0mYAykYiw [dev build]
https://s.olid.uk/id/JGf8PgQqSj6IP7tUolcgkg [prod build]

solid 1.x

10 still much faster, for this use case.

28ms for 100,000
1.4ms for 4000

playground [dev build]
playground [prod build]

[ryansolid]

Thanks for the follow-up measurement — confirmed, and here's the full picture with prod builds on the same machine (repro exactly as filed, 4000 iterations):

build	time
2.0.0-rc.0 (legacy store)	5.34 ms
2.0.0-rc.1 (store rewrite, pre-fix)	1371 ms
current next (rewrite + overlay fix)	5.72 ms
1.x	~1.4 ms

A few notes on the remaining gap:

The playground overstates it. The playground runs the dev build, which carries per-operation diagnostics (strict-read checks, affects witnessing, etc.). Prod is ~3x faster on this shape; 1.x dev adds almost nothing, so dev-to-dev comparisons skew against 2.0. Prod-to-prod the gap is ~4x, not 10x.

Where the 4x lives: commit boundaries, not writes. This benchmark takes a commit (flush()) every two writes — 4000 commits. Each 2.0 commit allocates a pending overlay of the committed backing, folds the written keys in, and notifies; profiled, that fixed cost is ~1 µs per commit. The same 8000 writes batched into fewer flushes run in 1.88 ms, i.e. ~0.23 µs per write — at parity with 1.x's per-write cost. 1.x has no commit concept at all (writes mutate the raw object and are immediately visible), which is also why it can't offer what the commit machinery buys: pending-until-flush isolation, async setters, actions, optimistic writes, and transitions over stores.

Both 2.0 store generations (rc.0's legacy store and the rewrite) land on the same ~1.3 µs/commit floor with completely different internals — it's the price of the semantics, not the implementation.

There is still headroom. For small commits with no transition active, the overlay allocation can be skipped in favor of a flat written-pairs list — that attacks ~25% of the profile (allocation + GC) and should bring this worst-case shape closer to 2–3x of 1.x. Tracking that as a post-release optimization.

Practical guidance: batch writes per flush where you can — per-write cost is already at 1.x parity, and flushing after every setter is the one shape where the fixed commit cost can't amortize.

[mizulu]

updated the playground links in the message above with both prod/dev builds.
no observable difference.
manual refresh of preview in playground until i see the fastest run

---

For the case of a single flush:

solid 2 - without flush after each write ( uses auto batching of solid 2.x)

count = 100000 fastest run : 172.4ms

https://s.olid.uk/id/15zhyRFWRBKHRVEljsby-w

import { createStore, onSettled } from "solid-js"

const COUNT = 100000
const [store, setStore] = createStore({})
const start = performance.now()

for (
  let i = 1; i < COUNT; i++
) {
  setStore(store => {
    store[i - 1] = false
    store[i] = true
  })

}
onSettled(() => {
  console.log(
    (performance.now() - start).toFixed(3),
    "ms"
  )
})

https://s.olid.uk/id/IshjmcTzRuO9NqsAw58D0A [ prod 2.0.0 @ 833efeb]

solid 1.x with batch

count = 100000 2 writes per iteration fastest run 89ms

import { render } from 'solid-js/web';
import { createSignal, createEffect, batch } from 'solid-js';

import { produce, createStore } from "solid-js/store"



const COUNT = 100000


const [store, setStore] = createStore({})


  const start = performance.now()

  batch(() => {
    for (
      let i = 1; i < COUNT; i++
    ) {


      setStore(
        produce(store => {
          store[i - 1] = false
          store[i] = true
        })

      );
    }
  })


  console.log((performance.now() - start).toFixed(3), "ms")

https://s.olid.uk/id/O0fFv_6-TO-aW5dquJcRCw [ 1.9.15 prod ]