benchmark comparison

altor-vec vs USearch

Portable ANN engine versus an aggressively small browser-focused package.

USearch is broader and appears across more environments, while altor-vec is narrower and more opinionated around frontend delivery. That means the comparison is less about raw algorithm prestige and more about what you are optimizing for.

These numbers are representative, not universal. Bundle size, query latency, and memory usage all vary with vector dimensions, index parameters, browser runtime, hardware, and whether embeddings are generated on device or ahead of time.

Comparison table

Category	altor-vec	USearch
Runtime model	Browser-first WebAssembly ANN runtime.	Portable vector search engine spanning multiple environments and bindings.
Bundle size / delivery	~54KB gzipped library payload.	Usually a larger or more complex integration depending on target runtime and build choice.
Query latency	Very fast local retrieval for shipped browser corpora.	Also optimized for fast ANN; exact wins depend on corpus size, SIMD, and build target.
Memory usage	Client memory budget remains the limiting factor.	Also constrained by local memory, though different internals may shift the curve.
Features	Purposefully narrow ANN workflow for the browser.	Broader engine ambitions and ecosystem reach beyond a small web-only package.
Dataset sweet spot	Frontend search and embedded app experiences.	Teams needing a more general ANN engine across runtimes may prefer it.

Where altor-vec wins

Smaller, more justifiable payload for web-product teams.
Opinionated simplicity for client-side delivery.
Good fit when the browser bundle is the product constraint.

Where USearch wins

Broader environment support and engine scope.
Potentially stronger fit outside purely browser-driven use cases.
May appeal to teams optimizing deeply across multiple platforms.

Honest decision guide

USearch is broader. altor-vec is narrower but easier to justify when your main constraint is shipping vector search inside a web app without dragging in a heavier stack.

The honest pattern across all of these benchmark pages is simple: if the search corpus should stay on the server, choose server-oriented infrastructure. If the search corpus is intentionally shipped with the product and the UX benefit of local retrieval matters more than backend scale, altor-vec is usually the more natural fit.

FAQ

Is USearch more powerful than altor-vec?

In scope, yes. But broader scope is not always better when the goal is a tiny, browser-friendly dependency.

What should frontend teams compare first?

Bundle impact, loading behavior, and whether the integration feels natural in the browser toolchain.

Can altor-vec still be the better choice if USearch is broader?

Yes. Narrow tools often win when they line up exactly with the product constraint.

Get started: npm install altor-vec · GitHub

Benchmark methodology

These measurements reflect altor-vec running in a controlled browser environment. All queries execute against a pre-built HNSW index loaded from a JSON file — no embedding generation time is included. Embeddings are generated once at build time.

Parameter	Value
Index size	10,000 vectors
Dimensions	384 (all-MiniLM-L6-v2)
HNSW M	16
ef_construction / ef_search	200 / 50
k	5
Browser	Chrome 124, M2 MacBook Pro
Measurement	p50/p95 of 1,000 consecutive queries

altor-vec latency (10K × 384d)

Metric	Result
p50 query latency	0.4ms
p95 query latency	0.8ms
Index load time	~35ms
Memory footprint	~17MB
WASM bundle size	54KB gzipped

What these numbers mean

Sub-millisecond latency means search is effectively instant from the user's perspective. Human perception of "instantaneous" begins around 100ms — altor-vec at p95 (0.8ms) is 125× faster than a cloud search call at 100ms total round-trip.

The 17MB footprint for 10K vectors fits easily in modern browser memory. For 100K vectors at 384 dimensions, expect ~170MB — viable on desktop, worth testing on mobile.

Run your own benchmark

import init, { WasmSearchEngine } from 'altor-vec';
await init();
const engine = WasmSearchEngine.from_vectors(vectors, DIM, 16, 200, 50);
const query = new Float32Array(DIM);
const times = [];
for (let i = 0; i < 1000; i++) {
  const t = performance.now();
  engine.search(query, 5);
  times.push(performance.now() - t);
}
times.sort((a, b) => a - b);
console.log('p50:', times[500].toFixed(2) + 'ms');
console.log('p95:', times[950].toFixed(2) + 'ms');