Signals at 10M Updates: Solid vs Svelte 5 vs Vue Vapor vs React Compiler — Reconciliation Latency, Memory, and True Cost per Million Interactions

A signal is not a performance feature. It is a dependency-tracking primitive: a source node holding a value and a version counter, plus a set of observers. Everything else — DOM bindings, memos, effects — is scheduling bookkeeping layered on that node.

When someone says "signals are faster than React," what they usually mean is that update cost scales with the number of nodes that actually changed rather than the number of components in the tree. That claim is real, measurable, and routinely mis-measured. This article defines reconciliation latency and cost-per-million-interactions (CPMI) precisely, gives you a harness that survives a design review, and dissects what Solid, Svelte 5 runes, Vue Vapor, and the React Compiler actually execute under load.

The Physics of a Signal: What You Are Actually Benchmarking

Push-Pull Graph Mechanics

Every production signals system implements the same three-phase cycle:

1. Write — a source assigns its value, bumps a version, and pushes its observer set onto a scheduler queue.
2. Invalidate — derived nodes are marked DIRTY or MAYBE_DIRTY transitively. No recomputation occurs yet; this is the pull half of the graph, and laziness is what prevents glitches.
3. Flush — the scheduler drains queued effects in topological order, re-running only nodes whose upstream version actually changed, then commits DOM mutations.

Cost is O(subscribers_of_changed_sources) + O(DOM_nodes_touched), and it is independent of total component count. That is the entire architectural argument, and it is the reason a signal-bound table cell can update in constant time inside a 100,000-row grid.

React's model is different in kind, not degree. setState schedules a lane; the renderer walks the fiber subtree from the nearest stateful ancestor, re-invokes function components, and reconciles children by key. Cost is O(elements_in_rendered_subtree) before the commit phase begins. The React Compiler does not change that shape — it shrinks the fraction of the tree that re-renders by caching element subtrees whose inputs are unchanged, converting many O(n) renders into O(1) renders. The commit is still a tree walk.

Why "10M Setter Calls" Is a Meaningless Benchmark

A tight for loop calling setCount(i) measures three different things in three frameworks:

• Solid: full propagation through the graph to every subscriber inside batch().
• Svelte 5: propagation plus scheduler dedupe; the DOM touches once at flush.
• React 18/19: writes collapse into a single scheduled render because everything is auto-batched — you are measuring a Set iteration and a lane merge.

Comparing those outputs is comparing a signal graph to Set.add. The unit must be defined at the level users feel.

Defining the Metric: Reconciliation Latency and CPMI

Event → Paint, Not Setter → Scheduler

The only latency a user experiences is input timestamp → next paint after commit. That is the INP-shaped metric (Interaction to Next Paint), and it is what you should report. Framework-internal timings are diagnostic, not authoritative.

The CPMI Formula

CPMI_mean_ms    = (1e6 / N) * Σ (t_paint_i − t_input_i)
CPMI_p99_ms     = p99(t_paint_i − t_input_i)
HeapFactor      = (heap_after_gc − heap_before_gc) / live_reactive_nodes
GCAmplified     = CPMI_mean_ms * (1 + major_gc_count / N)

Report all four. A framework that wins on mean latency but produces 18 ms tail commits will still fail your p99 budget on a mid-tier Android device. And a framework with a smaller heap-per-node can still lose on CPMI because GC pauses land inside the interaction.

Building a Harness You Can Defend

This harness measures event-to-paint latency and attributes blocking time via the longtask PerformanceObserver. It is framework-agnostic — you supply a driver that mutates state and lets the framework commit.

// bench/harness.ts
export interface InteractionSample {
  latencyMs: number;
  longTaskMs: number;
}

export type Driver = (i: number) => Promise<void> | void;

const nextPaint = (): Promise<number> =>
  new Promise((resolve) => {
    requestAnimationFrame(() =>
      requestAnimationFrame(() => resolve(performance.now()))
    );
  });

async function heapBytes(): Promise<number> {
  // Requires cross-origin isolation (COOP/COEP) in Chrome 107+.
  const perf = performance as Performance & {
    measureUserAgentSpecificMemory?: () => Promise<{ bytes: number }>;
    memory?: { usedJSHeapSize: number };
  };
  try {
    if (perf.measureUserAgentSpecificMemory) {
      const m = await perf.measureUserAgentSpecificMemory();
      return m.bytes;
    }
    return perf.memory?.usedJSHeapSize ?? Number.NaN;
  } catch {
    return Number.NaN; // not cross-origin isolated; fall back to CDP heap snapshots
  }
}

export async function measure(
  driver: Driver,
  n: number,
  opts: { warmup?: number } = {}
): Promise<{ samples: InteractionSample[]; heapDeltaBytes: number }> {
  const warmup = opts.warmup ?? Math.min(2_000, n);
  const samples: InteractionSample[] = [];
  let longTask = 0;

  const po = new PerformanceObserver((list) => {
    for (const e of list.getEntries()) longTask += e.duration;
  });
  try {
    po.observe({ type: 'longtask', buffered: false });
  } catch {
    // Safari lacks longtask; record NaN-adjacent zero and note it in the report.
  }

  for (let i = 0; i < warmup; i++) await driver(-1); // JIT + first-paint + hydration
  const before = await heapBytes();

  for (let i = 0; i < n; i++) {
    longTask = 0;
    const t0 = performance.now();
    await driver(i);
    const t1 = await nextPaint();
    samples.push({ latencyMs: t1 - t0, longTaskMs: longTask });
  }

  po.disconnect();
  const after = await heapBytes();
  return { samples, heapDeltaBytes: after - before };
}

Two operational notes. First, force GC between cohorts via CDP HeapProfiler.collectGarbage; otherwise run i inherits run i−1's garbage and your heap delta is fiction. Second, never trust a headless browser for paint timing — a missing compositor reports near-zero paint latency and silently invalidates every number in your table.

Framework-by-Framework Under Load

SolidJS — Compiled Bindings, Zero Virtual DOM

Solid compiles JSX directly to DOM instructions, so a signal update routes to a specific textContent assignment. batch() defers effect execution to a single flush, which is exactly what you want when measuring propagation cost rather than scheduler overhead.

// bench/solid.ts
import { batch, createEffect, createMemo, createRoot, createSignal } from 'solid-js';

export function run(n: number): { sink: number; ms: number } {
  const [count, setCount] = createSignal(0);
  const doubled = createMemo(() => count() * 2);
  let sink = 0;

  const dispose = createRoot((dispose) => {
    createEffect(() => {
      sink = doubled();
    });
    return dispose;
  });

  batch(() => {
    for (let i = 0; i < 10_000; i++) setCount(i);
  }); // warmup

  const t0 = performance.now();
  batch(() => {
    for (let i = 0; i < n; i++) setCount(i);
  });
  const ms = performance.now() - t0;

  dispose();
  return { sink, ms };
}

The failure mode here is ownership. An effect created outside an owner scope never gets disposed, and its closure retains every upstream node it touched. In a long-lived SPA that is a textbook leak, and it shows up in your heap delta as a linear slope across cohorts.

Svelte 5 Runes — Signals Generated by the Compiler

Svelte 5 runes compile to source/effect nodes in the client runtime. The critical difference from Solid is granularity of scheduling: $effect runs in a microtask by default, so flushSync() is mandatory if you want to attribute the commit to the same interaction.

// bench/svelte-runes.svelte.ts — note the .svelte.ts extension
import { flushSync, untrack } from 'svelte';

export function run(n: number): { sink: number; ms: number } {
  let count = $state(0);
  const doubled = $derived(count * 2);
  let sink = 0;

  // $effect requires an owner: root it explicitly outside a component.
  const destroy = $effect.root(() => {
    $effect(() => {
      sink = doubled;
    });
  });

  flushSync(() => {
    for (let i = 0; i < 10_000; i++) count = i;
  }); // warmup

  const t0 = performance.now();
  flushSync(() => {
    for (let i = 0; i < n; i++) count = i;
  });
  const ms = performance.now() - t0;

  destroy();
  return { sink: untrack(() => sink), ms };
}

For large immutable payloads, $state.raw replaces deep proxying with reference equality. Proxying a 50,000-element array of objects is the single most common cause of a "Svelte 5 is slower than Svelte 4" report — the reactivity system is fine; the proxy traps on every property read are not.

Vue Vapor — VDOM-Free Templates on the Vue Reactivity Core

Vapor compiles templates to direct DOM instructions while keeping the same @vue/reactivity graph: ref, computed, effect, effectScope. The win is the removal of the patch/patchKeyedChildren pass; the cost model of the graph itself is unchanged.

// bench/vue-reactivity.ts
import { computed, effect, effectScope, ref } from 'vue';

export function run(n: number): { sink: number; ms: number } {
  const scope = effectScope();
  const count = ref(0);
  const doubled = computed(() => count.value * 2);
  let sink = 0;

  scope.run(() => {
    effect(() => {
      sink = doubled.value;
    });
  });

  for (let i = 0; i < 10_000; i++) count.value = i; // warmup

  const t0 = performance.now();
  for (let i = 0; i < n; i++) count.value = i;
  const ms = performance.now() - t0;

  scope.stop(); // stop() halts all nested effects — do not skip this
  return { sink, ms };
}

Vue's scheduler deduplicates queued jobs by effect id into a microtask flush, so the loop above measures propagation and job enqueue, not commit. Use shallowRef + triggerRef for large arrays, and remember that every Vapor/VDOM interop boundary re-introduces a component boundary you were trying to delete.

React Compiler — Memoization, Not Reactivity

React has no signal graph. External signal stores integrate through useSyncExternalStore, which the compiler can only optimize around — it cannot make the subscription fine-grained for you.

// bench/ReactCounter.tsx
'use client';
import { memo, useSyncExternalStore } from 'react';

interface Signal<T> {
  get(): T;
  set(next: T): void;
  subscribe(l: () => void): () => void;
}

export function createSignal<T>(initial: T): Signal<T> {
  let value = initial;
  const listeners = new Set<() => void>();
  return {
    get: () => value,
    set(next: T) {
      if (Object.is(next, value)) return;
      value = next;
      for (const l of listeners) l();
    },
    subscribe(l: () => void) {
      listeners.add(l);
      return () => {
        listeners.delete(l);
      };
    },
  };
}

export const count = createSignal(0);

export const Counter = memo(function Counter() {
  const value = useSyncExternalStore(count.subscribe, count.get, count.get);
  return <output data-testid="out">{value}</output>;
});

With the compiler enabled, memo() is largely redundant; 'use no memo' opts a component out when the compiler bails (mutations during render, refs read in render, unknown hook aliasing). The performance consequence is asymmetry: per-write cost approaches zero because writes batch, but per-commit cost remains O(rendered elements). That is why React's startTransition trades mean latency for tail latency — chunking a 19 ms commit into yieldable slices raises average completion time while cutting the worst-case long task.

Measured Results: An Illustrative Table

These figures are order-of-magnitude and illustrative — generated on a single machine with a 1,000-row list where one cell changes per interaction. Absolute values do not transfer; the ratios and the tail behavior do. Reproduce with the harness above before citing anything.

The 3× CPMI gap is not an indictment of React — it is the price of a general-purpose render model that buys you concurrent scheduling, mature suspense, and a 10-year ecosystem. The signal frameworks buy you a flat update curve and pay for it in graph bookkeeping that you must own.

Memory: The Bill Arrives Later

Per-Signal Overhead Is Not the Problem

A source node plus its observer set costs tens of bytes. At 100,000 live signals that is single-digit megabytes. Nobody has ever failed an enterprise rollout because of per-node signal overhead.

Retention Is the Problem

• React double-buffering. The fiber alternate tree roughly doubles element memory during a render. Your heap delta per row in React is dominated by fibers, not state.
• Closures over DOM. An effect that captures a node reference keeps the whole subtree alive after unmount if you skipped cleanup.
• Memo caches. createMemo in Solid and computed in Vue retain their previous value. Memoizing a derived array retains the old array until the next recompute.
• Interop boundaries. Every Vapor/VDOM or runes/legacy-store boundary allocates a bridging wrapper that is easy to forget in teardown.

Trade-off Matrix for Enterprise Architecture

Pitfalls That Quietly Invalidate Your Numbers

• Measuring setter loops instead of interactions — silently meaningless for React.
• Forgetting flushSync in Svelte 5 or nextTick in Vue, so commit is attributed to the next interaction.
• Running dev builds with __DEV__ checks, source maps, and StrictMode double-invocation.
• No forced GC between cohorts; heap deltas accumulate noise.
• Headless rendering without a compositor, producing ~0 ms paint latency.
• Ignoring longtask attribution so a single 19 ms commit averages away into a fine-looking mean.
• Proxying large arrays ($state deep proxy) instead of using $state.raw / shallowRef.

Operational Checklist Before You Ship a Signal Architecture

• Publish CPMI mean, p99, and GC-amplified figures, not just mean.
• Verify every effect has an owner or an effectScope/$effect.root/createRoot teardown path.
• Confirm large collections use raw/shallow state, not deep proxies.
• Instrument production with PerformanceObserver({ type: 'longtask' }) and INP reporting.
• Budget heap per route, not heap total; regressions hide in route-level deltas.
• Re-run the harness on a throttled mid-tier device — 4× CPU slowdown changes rankings.

Sources & Technical References

• SolidJS official documentation — reactivity, batch, ownership: https://docs.solidjs.com/
• SolidJS reactivity source (createSignal, topological flush): https://github.com/solidjs/solid/blob/main/packages/solid/src/reactive/signal.ts
• Svelte 5 runes documentation: https://svelte.dev/docs/svelte/what-are-runes
• Svelte $state and $state.raw: https://svelte.dev/docs/svelte/$state
• Svelte flushSync and $effect.root API reference: https://svelte.dev/docs/svelte/svelte
• Svelte blog, "Introducing runes": https://svelte.dev/blog/runes
• Vue reactivity in depth (effect scopes, computed, scheduler): https://vuejs.org/guide/extras/reactivity-in-depth.html
• Vue core reactivity package source: https://github.com/vuejs/core/tree/main/packages/reactivity
• Vue.js official blog (Vapor mode and 3.6 release announcements): https://blog.vuejs.org/
• React Compiler documentation: https://react.dev/learn/react-compiler
• React useSyncExternalStore reference (tearing, external stores): https://react.dev/reference/react/useSyncExternalStore
• React 19 release notes: https://react.dev/blog/2024/12/05/react-19
• TC39 Signals proposal (standardization of the reactive graph model): https://github.com/tc39/proposal-signals
• MDN, Performance API and PerformanceObserver: https://developer.mozilla.org/en-US/docs/Web/API/Performance_API
• MDN, PerformanceLongTaskTiming: https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongTaskTiming
• web.dev, Interaction to Next Paint (INP): https://web.dev/articles/inp
• web.dev, measuring total page memory with measureUserAgentSpecificMemory(): https://web.dev/articles/monitor-total-page-memory-usage
• Krausest, js-framework-benchmark (methodology and caveats): https://github.com/krausest/js-framework-benchmark
• Chrome DevTools memory tooling documentation: https://developer.chrome.com/docs/devtools/memory
• V8 blog, garbage collection and heap measurement internals: https://v8.dev/blog