mirror of
https://github.com/readest/readest.git
synced 2026-07-09 16:00:16 +00:00
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>
|
||
|---|---|---|
| .. | ||
| index.ts | ||
| lib.ts | ||
| README.md | ||
| vector-retrieval.bench.ts | ||
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).