Experiments & Performance Over Time

resqlite was built through rigorous, benchmark-driven experimentation. This page tracks every dispositioned optimization attempt — accepted and rejected — alongside the performance data behind each decision. Use the headline charts for broad health, the scenario charts for app-shaped workloads, and click any data point to see the experiment and metrics that drove the decision.

Performance over time — lower is better

Every other tab plots one point per experiment, in experiment order. This one plots calendar time, and only runs that measure main — headline runs and the baseline-for-* arm of each A/B. A candidate arm measures a branch, so it is not history. Gaps are drawn as gaps: an unmeasured month should look like one.

Read Performance — lower is better

select() maps, selectBytes() JSON, and schema wide — 1K rows, wall time (ms). One point per experiment, in experiment order — not a time axis; see the Timeline tab for that. Hollow points are matched to a run by date heuristic rather than measured for that experiment. Dashed spans bridge runs dropped as noisy or built from a dirty tree — no point is plotted for them.

Write Performance — lower is better

Single inserts (100 sequential) and batch inserts (1K rows), wall time (ms)

Transactions — lower is better

Interactive transaction and transaction reads/writes, wall time (ms)

Concurrency & Parameterized — lower is better

4x concurrent reads and 100-query parameterized workload, wall time (ms)

Reactive Scenarios — lower is better

App-shaped reactive workloads: feed updates, sync bursts, keyed subscriptions, and high-cardinality fan-out

Reactive Micros — lower is better

Invalidation latency, small-stream fan-out, churn, and unchanged-result suppression

Point Query Throughput — higher is better

Single-row lookups per second, measuring dispatch latency floor
Loading…
Loading experiments...