Summary
add(&mut self, vectors: &[f32]) (all index types) requires a flat, row-major buffer. Callers who hold a Vec<Vec<f32>>, stream embeddings from a file, or receive rows from a model API must pre-allocate and flatten before calling add.
Ask
Add an ergonomic overload that takes rows without forcing a flatten, e.g.:
pub fn add_rows<R: AsRef<[f32]>, I: IntoIterator<Item = R>>(&mut self, rows: I)
// or
pub fn add_slice_of_slices(&mut self, rows: &[&[f32]])
It validates each row's length against dim (same guard as add) and feeds the existing internal storage path — no change to the on-disk format or internal layout. Internally it can still flatten into the contiguous buffer; the point is to remove that burden from the caller.
Notes
Loosely related to #38 (reduce hot-path allocations). Consider whether the iterator form can encode directly into the storage buffer to avoid an intermediate Vec.
Filed from an external technical review (May 2026); verified against v0.2.0.
Summary
add(&mut self, vectors: &[f32])(all index types) requires a flat, row-major buffer. Callers who hold aVec<Vec<f32>>, stream embeddings from a file, or receive rows from a model API must pre-allocate and flatten before callingadd.Ask
Add an ergonomic overload that takes rows without forcing a flatten, e.g.:
It validates each row's length against
dim(same guard asadd) and feeds the existing internal storage path — no change to the on-disk format or internal layout. Internally it can still flatten into the contiguous buffer; the point is to remove that burden from the caller.Notes
Loosely related to #38 (reduce hot-path allocations). Consider whether the iterator form can encode directly into the storage buffer to avoid an intermediate
Vec.Filed from an external technical review (May 2026); verified against v0.2.0.