Valdres

Performance

Continuously verified
These benchmarks run on every commit. If a regression is detected, the PR is blocked until performance is restored.

These benchmark the framework-agnostic core engine (atoms, selectors, families, transactions) head-to-head against Jotai v2.20.2 on the same CI runner, across two JavaScript engines: Bun (JavaScriptCore / Safari) and Node.js (V8 / Chrome). The figures below are the latest main run — refreshed automatically, nothing is excluded.

They measure the shared engine, not framework rendering. The React, Vue, Svelte, Solid, and Angular adapters build on each framework's own reactivity — Valdres rides on top of it rather than trying to outrun it, so adapter performance is bounded by the framework itself.

Atoms

BenchmarkSafari (JSC)Chrome (V8)
atom lifecycle (create+100get+100set)16.3x faster2.9x faster
atom(1)15.5x faster2.3x faster
get 1000 atoms30.2x faster6.8x faster
set 1000 atoms7.3x faster2.9x faster
set(atom, curr => curr+1)18.4x faster3.3x faster
set(atom, value)12.1x faster2.8x faster
set(atom) with 10 subs10.7x faster3.0x faster
store.get(atom)7.3x faster5.3x faster

Selectors

BenchmarkSafari (JSC)Chrome (V8)
selector(fn)8.4x faster1.5x slower
set + read 10 selectors3.8x faster1.3x faster
set + read 100 selectorFamily entries2.6x faster1.0x slower
set + read 100 selectors4.6x faster1.0x slower
set + read through 5 chained selectors3.0x faster1.3x faster

Transactions

BenchmarkSafari (JSC)Chrome (V8)
txn: 10 atoms × 10 selectors, set + read1.6x faster1.0x faster
txn: 10 atoms × 10 selectors, with subs5.0x faster2.7x faster
txn: 10 atoms × 100 selectors, set + read3.3x faster1.0x slower
txn: asymmetric DAG shared sink4.1x faster1.7x faster
txn: cross-atom 1000 selectors, set + read4.1x faster1.1x faster
txn: cross-atom 1000 selectors, with subs16.2x faster9.3x faster
txn: large asymmetric DAG (1000 leaves × 50 chain)5.1x faster2.0x faster

Store

BenchmarkSafari (JSC)Chrome (V8)
createStore16.2x faster1.3x faster
sub + unsub4.2x faster1.0x slower
sub+unsub on chain of 100 unsubscribed derived deps1.0x faster1.7x slower
sub+unsub on chain of 50 unsubscribed derived deps1.3x faster1.9x slower
sub+unsub on chain of 500 unsubscribed derived deps1.1x faster1.7x slower

Families

BenchmarkSafari (JSC)Chrome (V8)
atomFamily: txn update 5,000 existing members3.2x faster1.4x faster
atomFamily(id)1.4x faster1.7x faster
atomFamily(id) cache hit1.5x slower3.8x slower
atomFamily(string) cache hit1.3x slower4.8x slower
selectorFamily(id)1.5x faster7.1x slower
selectorFamily(string) cache hit2.1x slower2.5x slower

Other

BenchmarkSafari (JSC)Chrome (V8)
subscribe + unsubscribe 100 shared selector pairs1.0x faster2.6x slower
subscribe + unsubscribe 100 shared selector pairs + fan-in1.2x faster1.9x slower
subscribe + unsubscribe 100 shared selector pairs + fan-in + mounted spine1.8x slower3.5x slower
Where Valdres still trails Jotai

Honest accounting — these are the operations where Valdres is currently slower. They're tracked as optimization targets:

  • selector(fn) — Chrome (V8): 1.5x slower
  • set + read 100 selectorFamily entries — Chrome (V8): 1.0x slower
  • set + read 100 selectors — Chrome (V8): 1.0x slower
  • txn: 10 atoms × 100 selectors, set + read — Chrome (V8): 1.0x slower
  • sub + unsub — Chrome (V8): 1.0x slower
  • sub+unsub on chain of 100 unsubscribed derived deps — Chrome (V8): 1.7x slower
  • sub+unsub on chain of 50 unsubscribed derived deps — Chrome (V8): 1.9x slower
  • sub+unsub on chain of 500 unsubscribed derived deps — Chrome (V8): 1.7x slower
  • atomFamily(id) cache hit — Safari (JSC): 1.5x slower
  • atomFamily(id) cache hit — Chrome (V8): 3.8x slower
  • atomFamily(string) cache hit — Safari (JSC): 1.3x slower
  • atomFamily(string) cache hit — Chrome (V8): 4.8x slower
  • selectorFamily(id) — Chrome (V8): 7.1x slower
  • selectorFamily(string) cache hit — Safari (JSC): 2.1x slower
  • selectorFamily(string) cache hit — Chrome (V8): 2.5x slower
  • subscribe + unsubscribe 100 shared selector pairs — Chrome (V8): 2.6x slower
  • subscribe + unsubscribe 100 shared selector pairs + fan-in — Chrome (V8): 1.9x slower
  • subscribe + unsubscribe 100 shared selector pairs + fan-in + mounted spine — Safari (JSC): 1.8x slower
  • subscribe + unsubscribe 100 shared selector pairs + fan-in + mounted spine — Chrome (V8): 3.5x slower

Why the core is fast

The engine is optimized for minimal allocations and cache-friendly data structures — WeakMap-based storage with no intermediate objects, and transactions that batch updates so subscribers fire once.

In React specifically, the adapter is built on useSyncExternalStore (where Jotai uses useEffect + useReducer), which avoids extra renders and effect-cleanup overhead. The other adapters integrate with each framework's native reactivity — Vue refs, Svelte runes, Solid signals, Angular signals — so there the relevant performance is the framework's own.

What these numbers are (and aren't)
Every benchmark here compares the core Valdres engine against Jotai at the JavaScript level. They are not framework-rendering benchmarks, and Valdres does not claim to be faster than a framework's native reactivity (e.g. Svelte runes). The adapters exist to share one store across frameworks, not to outrun them.

Running benchmarks locally

# Bun (JSC/Safari engine)
bun run --cwd packages/valdres test:bench

# Node.js (V8/Chrome engine)
bun run --cwd packages/valdres test:bench:node

Performance is tracked over time on every push to main. View the live, always-current numbers and history at bencher.dev/perf/valdres.