Yichus and React Update-Enqueue Throughput Benchmark

This page runs three actual Bosatsu fixtures compiled through the Yichus sim --emit js path. The comparison uses React 18 production builds with ReactDOM.createRoot and useState. It measures how quickly each update API can be called in bounded batches under the selected batching configuration.

Measurement procedure and interpretation

Each engine receives 100 warmup calls. During a two-second sampling window, each timed batch stops after 1,000 update calls or when its timer reaches 8ms (an individual call can overshoot that time). Between batches the harness yields for at least 25ms so the browser can process pending work; it also waits for React's commit before continuing. Those waits are excluded from the reported call time. These bounded batches prevent an unbounded queue of React updates from exhausting the tab's memory.

“Ops/sec” therefore means update calls or enqueues divided by summed batch duration. It is not committed renders per second, frame rate, or end-to-end interaction latency. “Avg ms” is the same summed batch duration divided by call count, and “Speedup vs React” is the ratio of those enqueue-call averages. The startup value shown under each scenario is measured separately and is not included in update throughput. The per-call work is also engine-specific: React's list and targeted setters create copied state values, while the Yichus fixtures write a named state path.

Numbers vary by browser, machine, batching choice, and scheduler behavior. Run multiple times and compare only runs with the same controls.

Sources: single-state Bosatsu fixture, 10-item list Bosatsu fixture, 10-state targeted Bosatsu fixture, benchmark harness, and end-to-end harness test.

The Yichus batch size is the threshold for distinct pending binding paths before an immediate runtime flush; repeated writes to one path remain one pending path. Flush delay selects a microtask, synchronous flush, or 16ms delay. Keep both values fixed when comparing rows; the scenario labels state whether one counter, one of 10 list entries, or one of 10 scalar states is updated per call.