claude
65ee0f9c61
Search decoded the vector blob into a []float32 and JSON-unmarshalled the meta map for every row, then sorted all N and threw away everything past topK. Meta only ever matters for a survivor, and the sort answered a question a bounded heap answers cheaper. The scan still visits every row — that is what picks the winners. What it no longer does is allocate for a row it is about to discard. dotBlob reads the vector out of its stored bytes, so scoring costs nothing; a row is copied and its meta unmarshalled only once it has entered the topK. At 10000 rows and topK 10: 70.6ms to 26.8ms, 58MB to 17.5MB, 240k allocs to 60k. Recall is unchanged where it is measured. recall+onnx scores 22/32 with recall@1 70.4% and recall@3 85.2%, identical to before. TestMemoryStoreSearchMatchesNaive pins the ranking against the full-sort implementation it replaced, and TestDotBlobMatchesDot pins bit-identical scores, which the 0.008 gate margin demands. One behaviour did move: ties. sort.Slice is not stable, so equal scores were ordered arbitrarily; the heap now keeps the earliest. Under the real embedder an exact tie is a duplicate vector and nothing moved. Under the hash embedder the eval's floor uses, everything ties at 0 and that run's recall@3 went 74.1% to 81.5% — a number that measures tie order, not retrieval. recall@1 and false recall, the two the eval asserts, are unchanged on both runs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YMNNEkYx1mZFtHNrFk7uqb