forked from akai/readest
Huang Xin
2d819b476c
* fix(db): forward DatabaseOpts to tauri-plugin-turso NativeDatabaseService.open ignored its opts parameter, dropping any experimental feature flags (e.g. 'index_method' needed for FTS / vector indexes) and any encryption config before they could reach the Tauri plugin. Translate DatabaseOpts to the plugin's LoadOptions shape and forward as the single argument Database.load accepts. Skip translation when no relevant opts are set so the existing path-string call shape is preserved for callers without experimental/encryption needs. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(db): cover Turso vector primitives + add benchmark harness Verifies the Turso functions Reedy retrieval depends on, with a brute-force per-book kNN test that runs against every DatabaseService backend (node, native, WASM): SELECT vector_distance_cos(embedding, vector32(?)) AS d FROM book_chunks WHERE book_hash = ? ORDER BY d ASC LIMIT k This is the path Turso's own founder recommended in tursodatabase/turso#3778 ("First, focus on efficient SIMD-accelerated brute-force search") and what shipped at commit 1aba105df4f. Native vector index modules don't exist in this engine: `libsql_vector_idx`, `vector_top_k`, and `USING vector/hnsw/diskann/ivfflat` all parse-error against @tursodatabase/database@0.6.0-pre.28 (libsql_vector_idx is a libSQL/sqld fork feature; DiskANN was closed not-planned upstream in #832). The test asserts cross-book isolation and nearest-first ordering using only `WHERE book_hash = ?` and `ORDER BY` — no DDL, no identifier interpolation, no index plumbing. Also adds bench/ harness for manual perf checks: pnpm bench [name] run benchmarks (refuses in CI) pnpm bench --list list available benchmarks pnpm bench --no-record skip results.jsonl append pnpm bench --force override the CI guard Uses Node 24's --experimental-strip-types so no tsx devDep is needed. Appends one JSON line per run to bench/results.jsonl (gitignored, local history; share by pasting tabular stdout into PRs/issues). Explicitly NOT in CI — shared-tenant variance makes synthetic-benchmark regression detection unreliable; production telemetry (reedy_metrics, plan §M1.9) is the right tool for that. First benchmark: vector-retrieval. Measured on M1 Pro: 400 chunks × 384 dim → 0.35 ms / query 400 chunks × 768 dim → 0.45 ms / query 2000 chunks × 768 dim → 2.23 ms / query 10000 chunks × 768 dim → 14.00 ms / query 400 chunks × 1536 dim → 0.70 ms / query Per-chunk cost ~1.1 µs at 768 dim = ~1.4 ns/dim. NEON-class on Apple Silicon, ~50× faster than scalar — confirms SIMD acceleration is active in 0.6.0-pre.28. Per-query latency stays sub-ms at Reedy MVP corpus sizes; the ceiling is ~10K chunks per book before phone-class hardware notices. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Benchmarks
Manual performance benchmarks for the readest-app. Not run in CI — CI runners have shared-tenant variance that makes performance regression detection unreliable (numbers swing 2-10× between runs). These exist so anyone considering an architecture change can produce reproducible before/after numbers on their own hardware.
Run
pnpm bench # run every bench/*.bench.ts
pnpm bench vector-retrieval # run a single benchmark by name
pnpm bench --no-record # run but don't append to bench/results.jsonl
pnpm bench --list # list available benchmarks
Refuses to run when $CI is set. Append --force to override (don't unless
you've explicitly opted into running benches in CI for a one-off investigation).
Output
Each run prints a header with machine info (platform, CPU, Node version, key
package versions) followed by per-benchmark results. By default, results are
also appended to bench/results.jsonl (gitignored) — your personal local
history. To share numbers, paste the table from the terminal into a PR or issue.
When to add a new benchmark
When you're proposing an architecture change and need numbers to defend it. The benchmark should:
- Live at
bench/<name>.bench.ts. - Export
default { name, description, run(ctx) }matching the type inlib.ts. - Print human-readable results to stdout and return structured results to the
harness so they get logged to
results.jsonl. - Be self-contained — no fixtures outside
bench/, no I/O outside the bench directory and an in-memory database. - Run in under ~30 seconds at default sample sizes. If you need long-running scenarios, gate them behind a CLI flag.
When not to add a benchmark
- "Just in case" — performance infrastructure has carrying cost. Wait until you have a real architecture question that numbers will answer.
- To benchmark upstream libraries' performance (e.g., raw Turso function throughput). That belongs in the upstream project's bench suite.
- To gate CI on performance thresholds. CI variance makes that flaky; use
production telemetry (
reedy_metricstable) for regression detection against real workloads.
Existing benchmarks
vector-retrieval— proves Turso's brute-force vector search is SIMD-accelerated and fast enough for Reedy MVP corpus sizes (sub-millisecond at 400 chunks × 768 dim, ~14 ms at 10K chunks × 768 dim). Established the decision in plan §M1.5 to skip ANN indexes (which Turso doesn't ship anyway).