Performance Benchmark

Scenario: Derived Chain

A simple linear chain that measures pure overhead of each library’s reactive primitives:

• Loop: update counter synchronously from $1$ to $N$ ($N = 10^5$).
• Verify: final value $= N \times 4$.
• No diamond dependency — pure propagation overhead comparison.

Results

Library	Median (ms)	Min (ms)	Max (ms)	p95 (ms)	Ops/sec
SynState	13.39	10.28	20.04	19.62	7,465,632
RxJS	3.79	3.67	4.12	4.11	26,392,839
MobX	89.36	88.48	90.74	90.14	1,119,054
Jotai	392.07	374.80	426.35	420.00	255,059
Redux	202.22	191.80	251.83	242.93	494,500
Zustand	2.96	2.86	3.74	3.38	33,751,925
Valtio	22.04	21.25	22.82	22.82	4,537,372

Note

Results are auto-generated by pnpm --filter synstate run benchmark and embedded by pnpm --filter @synstate/docs run doc in https://github.com/noshiro-pf/synstate. Actual numbers vary depending on the machine and runtime environment.

Reading the numbers in context

RxJS, Zustand, and Valtio appear faster than SynState in this simple chain scenario. However, raw throughput on a linear chain does not tell the full story:

• RxJS is fast here because the graph has no diamond dependency. Once diamonds appear, combineLatest emits redundant intermediate values — $O(N^2)$ for wide diamonds and exponential for cascaded diamonds (generally $O(D^N)$ where $D$ is the fan-out per stage) — as shown in the diamond scenario below and the interactive demo. RxJS also suffers from glitches (inconsistent intermediate states), which SynState eliminates.
• Zustand and Valtio achieve their speed by computing derived values inline in a selector or callback (counter * 2 * 2). They have no mechanism to define independent derived values and combine them — which is why they are excluded from the Diamond Dependency scenario. In real applications, any state that requires combining multiple derived sources (form validation, computed styles, aggregated dashboards) cannot be expressed with these libraries’ vanilla APIs without manual orchestration.

SynState is the only library in this benchmark that is glitch-free, supports diamond dependencies, and maintains $O(n)$ propagation in all cases.

Implementation Details

Each library implements the same derived chain pattern. All implementations are runnable as vitest tests.

SynState

export const runBenchmark = (n: number): number => {
    const [counter, setCounter] = createState(0);

    const doubled = counter.pipe(map((x) => x * 2));

    const quadrupled = doubled.pipe(map((x) => x * 2));

    let mut_lastValue = 0;

    const subscription = quadrupled.subscribe((v) => {
        mut_lastValue = v;
    });

    for (let mut_i = 1; mut_i <= n; mut_i++) {
        setCounter(mut_i);
    }

    subscription.unsubscribe();

    return mut_lastValue;
};

RxJS

export const runBenchmark = (n: number): number => {
    const counter = new BehaviorSubject(0);

    const doubled = counter.pipe(map((x) => x * 2));

    const quadrupled = doubled.pipe(map((x) => x * 2));

    let mut_lastValue = 0;

    const subscription = quadrupled.subscribe((v) => {
        mut_lastValue = v;
    });

    for (let mut_i = 1; mut_i <= n; mut_i++) {
        counter.next(mut_i);
    }

    subscription.unsubscribe();

    return mut_lastValue;
};

MobX

export const runBenchmark = (n: number): number => {
    const state = observable({ counter: 0 });

    const doubled = computed(() => state.counter * 2);

    const quadrupled = computed(() => doubled.get() * 2);

    let mut_lastValue = 0;

    const dispose = reaction(
        () => quadrupled.get(),
        (value) => {
            mut_lastValue = value;
        },
        { fireImmediately: true },
    );

    for (let mut_i = 1; mut_i <= n; mut_i++) {
        runInAction(() => {
            state.counter = mut_i;
        });
    }

    dispose();

    return mut_lastValue;
};

Jotai

export const runBenchmark = (n: number): number => {
    const counterAtom = atom(0);

    const doubledAtom = atom((get) => get(counterAtom) * 2);

    const quadrupledAtom = atom((get) => get(doubledAtom) * 2);

    const store = createStore();

    let mut_lastValue = store.get(quadrupledAtom);

    const unsub = store.sub(quadrupledAtom, () => {
        mut_lastValue = store.get(quadrupledAtom);
    });

    for (let mut_i = 1; mut_i <= n; mut_i++) {
        store.set(counterAtom, mut_i);
    }

    unsub();

    return mut_lastValue;
};

Redux

export const runBenchmark = (n: number): number => {
    const counterSlice = createSlice({
        name: 'counter',
        initialState: { value: 0 },
        reducers: {
            set: (state, action: Readonly<{ payload: number }>) => {
                state.value = action.payload;
            },
        },
    });

    const store = configureStore({
        reducer: counterSlice.reducer,
        middleware: () => new Tuple(),
    });

    // eslint-disable-next-line unicorn/consistent-function-scoping
    const selectCounter = (state: Readonly<{ value: number }>): number =>
        state.value;

    const selectDoubled = createSelector(
        selectCounter,
        (counter) => counter * 2,
    );

    const selectQuadrupled = createSelector(
        selectDoubled,
        (doubled) => doubled * 2,
    );

    let mut_lastValue = selectQuadrupled(store.getState());

    store.subscribe(() => {
        mut_lastValue = selectQuadrupled(store.getState());
    });

    for (let mut_i = 1; mut_i <= n; mut_i++) {
        store.dispatch(counterSlice.actions.set(mut_i));
    }

    return mut_lastValue;
};

Zustand

export const runBenchmark = (n: number): number => {
    const store = createStore<Readonly<{ counter: number }>>()(() => ({
        counter: 0,
    }));

    const selectQuadrupled = (state: Readonly<{ counter: number }>): number =>
        state.counter * 2 * 2;

    let mut_lastValue = selectQuadrupled(store.getState());

    store.subscribe((state) => {
        mut_lastValue = selectQuadrupled(state);
    });

    for (let mut_i = 1; mut_i <= n; mut_i++) {
        store.setState({ counter: mut_i });
    }

    return mut_lastValue;
};

Valtio

export const runBenchmark = (n: number): number => {
    const state = proxy({ counter: 0 });

    let mut_lastValue = state.counter * 2 * 2;

    const unsubscribe = subscribe(
        state,
        () => {
            mut_lastValue = state.counter * 2 * 2;
        },
        true,
    );

    for (let mut_i = 1; mut_i <= n; mut_i++) {
        state.counter = mut_i;
    }

    unsubscribe();

    return mut_lastValue;
};

Scenario: Diamond Dependency

A diamond-shaped dependency graph that tests how each library handles multiple derived values merging back into one:

• Loop: update counter synchronously from $1$ to $N$ ($N = 10^5$).
• Verify: final value $= N \times 5$.
• Zustand is excluded because it has no mechanism to combine separate derived values.

RxJS Glitch

RxJS combineLatest fires the subscriber twice per update in this diamond graph (once with a stale value, once with the correct value). This doubled work is reflected in the benchmark results. See How SynState Solved the Glitch for details.

Results

Library	Median (ms)	Min (ms)	Max (ms)	p95 (ms)	Ops/sec
SynState	19.54	17.93	25.79	22.63	5,118,062
RxJS	9.31	8.86	9.68	9.57	10,737,673
MobX	99.90	98.57	101.49	101.28	1,000,966
Jotai	550.21	543.65	560.05	557.63	181,750
Redux	317.42	289.68	362.50	339.75	315,041

Implementation Details

SynState

export const runBenchmark = (n: number): number => {
    const [counter, setCounter] = createState(0);

    const doubled = counter.pipe(map((x) => x * 2));

    const tripled = counter.pipe(map((x) => x * 3));

    const sum = combine([doubled, tripled]).pipe(map(([d, t]) => d + t));

    let mut_lastValue = 0;

    const subscription = sum.subscribe((v) => {
        mut_lastValue = v;
    });

    for (let mut_i = 1; mut_i <= n; mut_i++) {
        setCounter(mut_i);
    }

    subscription.unsubscribe();

    return mut_lastValue;
};

RxJS

export const runBenchmark = (n: number): number => {
    const counter = new BehaviorSubject(0);

    const doubled = counter.pipe(map((x) => x * 2));

    const tripled = counter.pipe(map((x) => x * 3));

    const sum = combineLatest([doubled, tripled]).pipe(map(([d, t]) => d + t));

    let mut_lastValue = 0;

    const subscription = sum.subscribe((v) => {
        mut_lastValue = v;
    });

    for (let mut_i = 1; mut_i <= n; mut_i++) {
        counter.next(mut_i);
    }

    subscription.unsubscribe();

    return mut_lastValue;
};

MobX

export const runBenchmark = (n: number): number => {
    const state = observable({ counter: 0 });

    const doubled = computed(() => state.counter * 2);

    const tripled = computed(() => state.counter * 3);

    const sum = computed(() => doubled.get() + tripled.get());

    let mut_lastValue = 0;

    const dispose = reaction(
        () => sum.get(),
        (value) => {
            mut_lastValue = value;
        },
        { fireImmediately: true },
    );

    for (let mut_i = 1; mut_i <= n; mut_i++) {
        runInAction(() => {
            state.counter = mut_i;
        });
    }

    dispose();

    return mut_lastValue;
};

Jotai

export const runBenchmark = (n: number): number => {
    const counterAtom = atom(0);

    const doubledAtom = atom((get) => get(counterAtom) * 2);

    const tripledAtom = atom((get) => get(counterAtom) * 3);

    const sumAtom = atom((get) => get(doubledAtom) + get(tripledAtom));

    const store = createStore();

    let mut_lastValue = store.get(sumAtom);

    const unsub = store.sub(sumAtom, () => {
        mut_lastValue = store.get(sumAtom);
    });

    for (let mut_i = 1; mut_i <= n; mut_i++) {
        store.set(counterAtom, mut_i);
    }

    unsub();

    return mut_lastValue;
};

Redux

export const runBenchmark = (n: number): number => {
    const counterSlice = createSlice({
        name: 'counter',
        initialState: { value: 0 },
        reducers: {
            set: (state, action: Readonly<{ payload: number }>) => {
                state.value = action.payload;
            },
        },
    });

    const store = configureStore({
        reducer: counterSlice.reducer,
        middleware: () => new Tuple(),
    });

    // eslint-disable-next-line unicorn/consistent-function-scoping
    const selectCounter = (state: Readonly<{ value: number }>): number =>
        state.value;

    const selectDoubled = createSelector(
        selectCounter,
        (counter) => counter * 2,
    );

    const selectTripled = createSelector(
        selectCounter,
        (counter) => counter * 3,
    );

    const selectSum = createSelector(
        selectDoubled,
        selectTripled,
        (doubled, tripled) => doubled + tripled,
    );

    let mut_lastValue = selectSum(store.getState());

    store.subscribe(() => {
        mut_lastValue = selectSum(store.getState());
    });

    for (let mut_i = 1; mut_i <= n; mut_i++) {
        store.dispatch(counterSlice.actions.set(mut_i));
    }

    return mut_lastValue;
};

Scenario: Deep Chain Throughput

The first two scenarios use fixed-size graphs. This scenario matches the Throughput interactive demo: a depth-$M$ scan chain where each stage lerps toward the previous stage, with a combine that reads all $M+1$ outputs. $K$ source updates are pushed synchronously per measurement — simulating $K$ updates per animation frame.

The following diagram shows the graph structure at $M = 3$. In the actual benchmark, $M$ ranges from $50$ to $200$:

• $K$ (updates per measurement): $100$, $500$, $1000$.
• $M$ (chain depth): $50$, $100$, $200$.
• Zustand, Valtio, and Redux are excluded (no mechanism to express a stateful scan chain with independent derived values).
• Measurements exceeding 5,000 ms are aborted.

Why RxJS is $O(M^2)$ per source update

combineLatest subscribes to all $M+1$ inputs (source + $M$ scan stages). When source emits a new value, RxJS’s depth-first propagation causes the following cascade:

1. source emits → combineLatest fires (1st subscriber call; scan₁–scanₘ still hold old values)
2. source’s change propagates to scan₁ → scan₁ emits → combineLatest fires (2nd call; scan₂–scanₘ still old)
3. scan₁’s change propagates to scan₂ → scan₂ emits → combineLatest fires (3rd call)
4. … this continues through the entire chain …
5. scanₘ emits → combineLatest fires ($M+1$th call — all values are now up to date)

Each of these $M+1$ combineLatest emissions invokes the subscriber, which processes $M+1$ values → $O(M)$ work per call. So a single source update costs $O(M) \times (M+1)$ = $O(M^2)$.

SynState’s combine waits until the entire propagation order is resolved before emitting — 1 subscriber call per source update, $O(M)$ total.

Results

Library	K=100, M=50	K=500, M=50	K=1000, M=50	K=100, M=100	K=500, M=100	K=1000, M=100	K=500, M=200	K=1000, M=200
SynState	0.4 ms	1.0 ms	1.5 ms	0.3 ms	1.6 ms	2.8 ms	2.9 ms	5.6 ms
RxJS	3.3 ms	14.6 ms	31.1 ms	14.2 ms	66.7 ms	135.0 ms	335.3 ms	678.4 ms
Jotai	9.2 ms	46.5 ms	91.3 ms	17.2 ms	89.6 ms	182.9 ms	194.5 ms	398.5 ms
MobX	18.9 ms	79.4 ms	156.2 ms	30.0 ms	150.1 ms	289.9 ms	289.8 ms	575.2 ms

Key observations

• SynState scales linearly with both $K$ and $M$ — at $K=1000$, $M=200$, it finishes in 5.6 ms. Its push-based direct function calls have negligible per-stage overhead.
• RxJS takes 678 ms at $K=1000$, $M=200$ — 121× slower than SynState. As explained above, this is not a constant-factor difference but a quadratic $O(M^2)$ asymptotic cost from combineLatest’s redundant emissions. The same blowup is visible in the interactive demo.
• Jotai takes 399 ms at $K=1000$, $M=200$ — 71× slower than SynState — due to selectAtom’s per-update overhead (epoch-based recomputation and dynamic dependency tracking on every propagation step).
• MobX takes 575 ms at $K=1000$, $M=200$ — 103× slower than SynState. This scenario requires scan (stateful accumulation: each stage needs its own previous value plus the new input). MobX’s computed cannot express this because it is a pure derivation with no access to its own previous output. The only option is observable.box + reaction (push-based), which incurs per-stage overhead from proxy tracking, dependency notification, and autorun re-reads. In contrast, the cascaded diamond scenario uses stateless derivations that computed can handle efficiently via lazy evaluation.
• At $K=500$, $M=100$ — a realistic scenario for 60fps animation with moderate graph complexity — SynState (1.6 ms) comfortably fits within the 16ms frame time, while RxJS (67 ms), Jotai (90 ms), and MobX (150 ms) all far exceed it.

Scenario: Cascaded Diamond

This scenario demonstrates the exponential blowup of RxJS’s combineLatest when diamonds are chained in series. Each stage splits the previous output into two branches (fan-out $D = 2$) and recombines them, creating a chain of $N$ binary diamonds:

The diagram shows $N = 3$. In the benchmark, $N$ ranges from $2$ to $20$.

• $K$ (source updates): $100$.
• $N$ (cascade depth): $2, 4, 6, 8, 10, 12, 14, 16, 18, 20$.
• Measurements exceeding 5,000 ms are aborted.

Why RxJS is $O(2^N)$ per source update in this benchmark

Each combineLatest in the chain fires twice per upstream emission (once for the left branch, once for the right). These doublings cascade: stage 1 fires 2 times, stage 2 fires 4, stage 3 fires 8, …, stage $N$ fires $2^N$ times. At $N=14$ ($K=100$), RxJS spends nearly 2 seconds; at $N=16$, it exceeds the 5-second timeout. More generally, for a fan-out of $D$ branches per diamond, the cost would be $O(D^N)$.

Results

Library	N=2	N=4	N=6	N=8	N=10	N=12	N=14	N=16	N=18	N=20
SynState	0.5 ms	0.6 ms	0.5 ms	0.5 ms	0.8 ms	1.9 ms	6.2 ms	23.1 ms	90.8 ms	359.2 ms
RxJS	0.2 ms	0.5 ms	2.1 ms	11.1 ms	60.2 ms	373.9 ms	2018.1 ms	> 5000 ms	> 5000 ms	> 5000 ms
Jotai	1.5 ms	1.9 ms	2.5 ms	5.3 ms	7.2 ms	13.0 ms	35.9 ms	116.4 ms	414.5 ms	1666.5 ms
MobX	1.0 ms	0.6 ms	0.9 ms	0.8 ms	0.9 ms	0.9 ms	1.0 ms	1.1 ms	1.2 ms	1.3 ms

Key observations

• RxJS exhibits classic $O(2^N)$ exponential growth (binary fan-out). It times out at $N=16$ ($2^{16} = 65536$ emissions per source update $\times 100$ updates). At $N=14$, it already takes 2,018 ms — over 300× slower than SynState (6.2 ms).
• MobX stays under 1.3 ms even at $N=20$, thanks to its lazy computed evaluation. MobX’s computed values are not eagerly re-evaluated when their dependencies change — they are only recomputed when read. The reaction reads only the final computed, which triggers a single lazy pass through the chain. Each computed in the chain is evaluated exactly once per update, yielding $O(N)$ total work with minimal overhead. This contrasts sharply with the deep chain throughput scenario where MobX is 103× slower than SynState — because that scenario uses a chain of reactions (push-based), not computeds (pull-based). The performance characteristics depend heavily on which MobX primitive is used.
• SynState propagates in $O(N)$ via depth-ordered traversal, but the benchmark includes graph construction cost in each runBenchmark call (creating $3N+1$ observables with binary search insertion into propagationOrder). This construction overhead grows with $N$ and dominates at large depths. At $N=20$, SynState takes 359 ms. In applications where the graph is constructed once and updated many times, the per-update cost is $O(N)$ as shown in the deep chain throughput scenario.
• Jotai grows faster than $O(N)$ due to its per-store.set() DFS overhead compounding with the number of derived atoms. At $N=20$, it takes 1,667 ms.

Scenario: Conditional Fan-Out

The previous scenarios test propagation throughput — every source update reaches the subscriber. This scenario tests a different pattern: the cost of updating an observable that is not in the subscription set — the case where dynamic dependency tracking is most advantageous.

The graph has B branches and a selector. The selector is fixed at $0$ throughout the benchmark, so only branch[0] is “active”. The benchmark updates branch[1] (an inactive branch) $K = 10^5$ times.

The key difference between libraries is whether branch[1] has any observers (subscribers):

• Static subscriptions (SynState, RxJS): combine subscribes to all branches at construction time, so branch[1] has an observer. When branch[1] is updated, combine fires, map produces the same value as before, and equality comparison prevents downstream propagation. Cost scales with B because the combined array grows.
• Dynamic subscriptions (Jotai, MobX): The computed or derived atom only subscribes to observables that were actually accessed via .get() during execution. When selector = 0, only branch[0].get() is called, so branch[1]’s observer list is empty. Updating branch[1] has nothing to notify — nothing happens.

Results

Library	B=2	B=5	B=10	B=20	B=50	B=100	B=200	B=500	B=1000
SynState	24.2 ms	24.2 ms	33.7 ms	48.1 ms	90.8 ms	154.0 ms	297.4 ms	703.3 ms	1466.0 ms
RxJS	5.6 ms	5.3 ms	5.1 ms	5.4 ms	6.1 ms	9.2 ms	22.3 ms	37.2 ms	61.4 ms
Jotai	69.6 ms	69.8 ms	73.7 ms	68.8 ms	72.1 ms	69.0 ms	70.5 ms	72.5 ms	69.9 ms
MobX	2.3 ms	2.5 ms	2.4 ms	2.4 ms	2.4 ms	2.4 ms	2.4 ms	2.4 ms	2.7 ms

Key observations

• MobX is the fastest in this scenario. computed(() => branches[selector.get()].get()) subscribes only to selector and branches[0] at runtime, so branches[1]’s observer list is empty. Updating branches[1] has no one to notify — the cost is constant at ~2.4 ms regardless of B.

• SynState’s cost scales linearly with B because combine subscribes to all branches at construction time, so any branch update fires the combine. The linear trend is clearly visible in the chart: from 24 ms at B=2 to 1,466 ms at B=1000 (~1.5μs per update per branch).

• RxJS uses the same static combineLatest approach. Its cost also scales with B but more slowly than SynState, because combineLatest does not perform equality comparison — it always emits, and the subscriber does minimal work (assigning a value).

• Jotai uses dynamic subscriptions like MobX — resultAtom does not subscribe to the inactive branch, so no recomputation is triggered. However, store.set() itself performs bookkeeping operations (invalidation checks) inside the atom store, producing a constant overhead of ~70 ms regardless of B. This makes Jotai slower than SynState for B≤50.

  This benchmark is an intentionally favorable scenario for dynamic subscriptions

  This benchmark is designed to illustrate the theoretical difference between static and dynamic subscriptions, and intentionally constructs conditions most favorable to the dynamic subscription side.

  In real applications, a selector staying fixed while an inactive branch receives a large volume of updates is an unlikely scenario. If unused data is being frequently updated, that is an application-level design issue rather than a limitation of the library’s subscription model. For example, if a WebSocket feed for a hidden channel continues to push updates, the correct fix is to stop the subscription itself, regardless of which library is used.

  Additionally, this benchmark does not include selector switches. In real applications, each selector change requires MobX/Jotai to rebuild the subscription set (unsubscribe from old dependencies, subscribe to new ones), and that cost is not measured here.

Implementation details

SynState

export const runBenchmark = (k: number, branchCount: number): number => {
    const [selector] = createState(0);

    const branches: DeepReadonly<
        {
            source: Observable<number>;
            set: (v: number) => void;
        }[]
    > = Arr.zeros(asUint32(branchCount)).map(() => {
        const [source, setSource] = createState(0);

        return { source, set: setSource };
    });

    const allSources = [
        selector,
        ...branches.map((b) => b.source),
    ] as const satisfies NonEmptyArray<Observable<number>>;

    const result = combine(allSources).pipe(
        map(
            ([selectorValue, ...branchesValue]) =>
                branchesValue[selectorValue] ?? 0,
        ),
    );

    let mut_lastValue = 0;

    const subscription = result.subscribe((v) => {
        mut_lastValue = v;
    });

    // Update an INACTIVE branch (branch 1, while selector = 0)
    const inactiveBranch = branches[1];

    if (inactiveBranch === undefined) {
        throw new Error('need at least 2 branches');
    }

    for (let mut_i = 1; mut_i <= k; mut_i++) {
        inactiveBranch.set(mut_i);
    }

    subscription.unsubscribe();

    return mut_lastValue;
};

RxJS

export const runBenchmark = (k: number, branchCount: number): number => {
    const selector = new BehaviorSubject(0);

    const branches: readonly BehaviorSubject<number>[] = Arr.zeros(
        asUint32(branchCount),
    ).map(() => new BehaviorSubject(0));

    const result = combineLatest([selector, ...branches]).pipe(
        map((values) => {
            const sel = values[0];

            return values[sel + 1] ?? 0;
        }),
    );

    let mut_lastValue = 0;

    const subscription = result.subscribe((v) => {
        mut_lastValue = v;
    });

    // Update an INACTIVE branch (branch 1, while selector = 0)
    const inactiveBranch = branches[1];

    if (inactiveBranch === undefined) {
        throw new Error('need at least 2 branches');
    }

    for (let mut_i = 1; mut_i <= k; mut_i++) {
        inactiveBranch.next(mut_i);
    }

    subscription.unsubscribe();

    return mut_lastValue;
};

MobX

export const runBenchmark = (k: number, branchCount: number): number => {
    const selector = observable.box(0);

    const branches: readonly ReturnType<typeof observable.box<number>>[] =
        Arr.zeros(asUint32(branchCount)).map(() => observable.box(0));

    // Dynamic dependency: only tracks the branch selected by selector
    const result = computed(() => {
        const sel = selector.get();

        const target = branches[sel];

        if (target === undefined) {
            return 0;
        }

        return target.get();
    });

    let mut_lastValue = 0;

    const dispose = reaction(
        () => result.get(),
        (value) => {
            mut_lastValue = value ?? 0;
        },
        { fireImmediately: true },
    );

    // Update an INACTIVE branch (branch 1, while selector = 0)
    const inactiveBranch = branches[1];

    if (inactiveBranch === undefined) {
        throw new Error('need at least 2 branches');
    }

    for (let mut_i = 1; mut_i <= k; mut_i++) {
        inactiveBranch.set(mut_i);
    }

    dispose();

    return mut_lastValue;
};

Jotai

export const runBenchmark = (k: number, branchCount: number): number => {
    const selectorAtom = atom(0);

    const branchAtoms: readonly WritableAtom<
        number,
        Mutable<readonly [number]>,
        void
    >[] = Arr.zeros(asUint32(branchCount)).map(() => atom(0));

    // Dynamic dependency: only reads the branch selected by selectorAtom
    const resultAtom = atom((get) => {
        const sel = get(selectorAtom);

        const targetAtom = branchAtoms[sel];

        if (targetAtom === undefined) {
            return 0;
        }

        return get(targetAtom);
    });

    const store = createStore();

    let mut_lastValue = store.get(resultAtom);

    const unsub = store.sub(resultAtom, () => {
        mut_lastValue = store.get(resultAtom);
    });

    // Update an INACTIVE branch (branch 1, while selector = 0)
    const inactiveBranchAtom = branchAtoms[1];

    if (inactiveBranchAtom === undefined) {
        throw new Error('need at least 2 branches');
    }

    for (let mut_i = 1; mut_i <= k; mut_i++) {
        store.set(inactiveBranchAtom, mut_i);
    }

    unsub();

    return mut_lastValue;
};

Methodology

• Warmup: 5 rounds (discarded).
• Measured: 20 rounds.
• $N$: $10^5$ updates per round.
• Timing: performance.now() (sub-millisecond precision).
• Statistics: median, min, max, p95, ops/sec (based on median).

Fairness Notes

• Redux: Default middleware (thunk, serializable check, immutability check) is disabled via middleware: () => new Tuple(). These are development-time checks that are tree-shaken in production builds.
• Zustand (Derived Chain only): Derived values are computed inline in the selector (counter * 2 * 2) since Zustand does not have a separate derived-value primitive. Zustand is excluded from the Diamond Dependency scenario for the same reason — there is no mechanism to define independent derived values and combine them.
• Valtio (Derived Chain only): Like Zustand, derived values are computed inline inside the subscribe callback (state.counter * 2 * 2) since Valtio’s derive utility is a separate package and the vanilla API does not provide a built-in derived-value primitive. The third argument true enables synchronous notification so that the subscriber fires on every mutation (Valtio batches asynchronously by default). Valtio is excluded from the Diamond Dependency scenario for the same reason.
• RxJS (Diamond Dependency): combineLatest fires the subscriber twice per source update due to the glitch problem. The benchmark measures wall-clock time including this extra work, which reflects the real-world cost of diamond dependencies in RxJS.
• MobX: reaction is used instead of autorun to match other libraries’ subscribe-and-record pattern. runInAction wraps each mutation as required by MobX strict mode.
• Jotai: store.sub() does not pass the current value to the callback, so an additional store.get() call is made inside the listener. The initial value is also read via store.get() before subscribing.
• All libraries create their state, derived values, and subscriptions inside the benchmark function. Setup cost is included in the measurement.

Analysis: Why Jotai Is ~29× Slower

Jotai is the slowest library in both scenarios despite having glitch-free semantics. The root cause is per-update framework overhead — work that Jotai’s store performs on every store.set() call, regardless of graph size.

Per-update cost breakdown

When store.set(counterAtom, i) is called, Jotai’s store executes these steps:

1. Value update — write the new value and compare with Object.is. $O(1)$.
2. Invalidation pass (invalidateDependents) — DFS traversal of all mounted dependents, marking each as “needs recomputation” via epoch number tracking in a Map<Atom, EpochNumber>. $O(N)$ where $N$ = number of affected atoms.
3. Topological sort (recomputeInvalidatedAtoms) — a second DFS post-order traversal using WeakSet for visit tracking, producing a correctly ordered list of atoms to recompute. $O(N)$.
4. Recomputation — for each atom in topological order, execute its read function. Inside the read function, each get(dep) call: (a) looks up the dependency’s AtomState, (b) compares epoch numbers to check staleness, (c) records the dependency in a Map for future invalidation. The cost is $O(\sum D_i)$ — the sum of direct dependencies across all recomputed atoms, not the product. In a chain of N atoms each with 1 dependency, this is $O(N)$.
5. Subscriber notification — fire listener callbacks. Jotai’s store.sub() does not pass the new value, so the callback must call store.get() again, triggering an additional cache lookup. $O(1)$ per listener, but adds one extra traversal.

Comparison with SynState

Step	SynState	Jotai
Graph resolution	Once at construction time	Every store.set() (steps 2–3)
Propagation	Direct function calls through pre-built subscription chain	read function execution with getter spy + Map/WeakSet operations
Dependency tracking	Static (set at construction time)	Dynamic (rediscovered on every evaluation via getter spy)
Staleness check	Not needed (push-based)	Epoch number comparison per get() call
Subscriber value delivery	Value passed directly to callback	Callback must call store.get() to read the value

Where the constant-factor difference is visible

The benchmark loop runs 100,000 updates to make the per-update difference measurable. But these constant-factor costs also matter in real applications with high-frequency events.

For example, mousemove and pointermove events fire dozens of times per second. If each event triggers a reactive pipeline — such as a drag-and-drop handler, a tooltip position, or a canvas animation — the per-update overhead is multiplied by the event rate. At higher chain depths, the gap becomes dramatic: in the Throughput demo (depth-100 chain, 500 updates per frame), Jotai’s ms/frame exceeds the 16ms budget and visibly stutters, while SynState stays well within budget.

The root cause of the per-update gap:

• SynState: setCounter(i) → call doubled’s map function → call quadrupled’s map function → call subscriber. Three direct function calls with no framework bookkeeping.
• Jotai: store.set(counterAtom, i) → DFS invalidation (WeakSet alloc + Map writes) → DFS topological sort (WeakSet alloc + array push + reverse) → recompute doubledAtom (Map lookup + epoch check + Map write) → recompute quadrupledAtom (same) → flush callback → store.get(quadrupledAtom) (cache lookup).

Over 100,000 iterations, SynState’s three function calls dominate, while Jotai’s per-update bookkeeping (Map/WeakSet allocations, epoch comparisons, two DFS traversals) accumulates into the observed ~29× difference.