Wikipedia search · Method and limitations

Same vectors. Four paths. Three storage layouts.

This experimental lab does not change the library. It compares its existing IndexedDB cosine query against an in-memory JavaScript scan, WASM-SIMD and WebGPU matrix-vector scoring. Top-k IDs and score errors stay visible, including disagreement.

Synthetic Float32 vectors, not semantic embeddings. GPU upload is measured once, separately. Queries include readback and JavaScript top-k. Unsupported engines show their actual error; no silent fallback or assumed hardware speed.

This writes temporary IndexedDB and OPFS data on this origin. 100k × 128 uses 51.2 MB per packed copy, with additional CPU/GPU copies and larger Array records. Database cleanup finishes when this page closes because the current library has no close API. Runs may briefly block the main thread.

Ready. Nothing runs until you press Run.

What is being tested?

The prior research predicted 6–51 ms upload for 51.2 MB and estimated an IndexedDB/scoring split of roughly 666/130 ms. Neither was a local measurement. This lab measures the upload and storage directly; cursor read includes materialisation, not a separately instrumented deserialisation phase.

Snapshot storage sacrifices per-record mutation and metadata-index semantics. OPFS also requires a format, key map and recovery strategy. Fast bulk reads alone do not justify replacing IndexedDB. GPU and SIMD use Float32 arithmetic; JavaScript uses double accumulators, so bit-identical scores are not promised. Near ties may reorder neighbours.