tensor_store Benchmarks

The tensor store uses DashMap (sharded concurrent HashMap) for thread-safe key-value storage.

Core Operations

Scan Operations (10k total items, parallel)

Concurrent Write Performance

Mixed Workload

Analysis

• Read vs Write: Reads are ~20% faster than writes due to DashMap’s read-optimized design
• Scaling: Near-linear scaling up to 10k items; slight degradation at scale due to hash table growth
• Concurrency: DashMap’s 16-shard design provides excellent concurrent performance
• Contention: Under high contention, performance actually improves at 8 threads vs 4 (lock sharding distributes load)
• Parallel scans: Uses rayon for >1000 keys (25-53% faster)
• scan_count vs scan: Count-only is ~5x faster (avoids string cloning)

Bloom Filter (optional)

Sparse Lookups (1K keys in store)

Note: Bloom filter adds ~15ns overhead for in-memory DashMap stores. It’s designed for scenarios where the backing store is slower (disk, network, remote database), where the early rejection of non-existent keys avoids expensive I/O.

Snapshot Persistence (bincode)

Each item is a TensorData with 3 fields: id (i64), name (String), embedding (128-dim Vec<f32>).

Snapshot File Sizes

Snapshot Analysis

• Throughput: ~1M items/second for both save and load
• Atomicity: Uses temp file + rename for crash-safe writes
• Bloom filter overhead: ~3-5% slower to rebuild filter during load
• Scaling: Near-linear with dataset size
• File size: ~600 bytes per item with 128-dim embeddings (dominated by vector data)

Write-Ahead Log (WAL)

WAL provides crash-consistent durability with minimal performance overhead. Benchmarks use same payload as in-memory tests (128-dim embeddings).

WAL Writes

WAL Recovery

WAL Analysis

• Near constant recovery time: Recovery is dominated by file open overhead (~400us), not record count
• Sequential I/O: WAL replay reads sequentially, hitting 25M records/sec
• Durable vs in-memory: WAL writes at 1.4M ops/sec vs 2.0M ops/sec in-memory (72% of in-memory speed)
• Use case: Production deployments requiring crash consistency

All engines support WAL via open_durable():

#![allow(unused)]
fn main() {
// Durable graph engine
let engine = GraphEngine::open_durable("data/graph.wal", WalConfig::default())?;

// Recovery after crash
let engine = GraphEngine::recover("data/graph.wal", &WalConfig::default(), None)?;
}

Sparse Vectors

SparseVector provides memory-efficient storage for high-sparsity embeddings by storing only non-zero values.

Construction (768d)

Dot Product (768d)

Memory Compression

Sparse Vector Analysis

• High sparsity sweet spot: At 99% sparsity, dot products are 15-22x faster than dense
• Memory scaling: Compression ratio = 1 / (1 - sparsity), so 99% sparse = ~100x smaller
• Construction overhead: Negligible (~1us per vector)
• Use case: Embeddings from sparse models, one-hot encodings, pruned representations

Delta Vectors

DeltaVector stores embeddings as differences from reference “archetype” vectors, ideal for clustered embeddings.

Construction (768d, 5% delta)

Dot Product (768d, precomputed archetype dot)

Same-Archetype Dot Product (768d)

Delta Memory (768d)

Archetype Registry (8 archetypes, 768d)

Delta Vector Analysis

• Precomputed speedup: With archetype dot products cached, 6.5x faster than dense
• Cluster-friendly: Similar vectors share archetypes, deltas are sparse
• Use case: Semantic embeddings that cluster (documents, user profiles, products)

K-means Clustering

K-means discovers archetype vectors automatically from embedding collections.

K-means fit (128d, k=5)

Varying k (1000 vectors, 128d)

K-means Analysis

• K-means++ is faster: Better initial centroids mean fewer iterations to converge
• Linear with n: Doubling vectors roughly doubles time
• Quadratic with k at high k: Each iteration is O(n*k), and more clusters need more iterations
• Use case: Auto-discover archetypes for delta encoding, cluster analysis, centroid-based search