Benchmarks

Performance measurements for AgenticMemory's core operations across various graph sizes. All benchmarks use the Rust engine directly; Python SDK overhead is negligible for I/O-bound operations and adds approximately 5-15 microseconds per FFI call for compute-bound operations.

Test Environment

All benchmarks are run with cargo bench using release-mode compilation with link-time optimization. Results represent the median of 100 iterations after warm-up, with 95% confidence intervals.

Summary Results

Headline numbers measured at 10K nodes, 50K edges:

Detailed Results by Graph Size

Add Node

Time to insert a single cognitive event (fact with 200-character content and metadata) into the in-memory graph.

Node insertion is O(1) amortized. Performance is dominated by the hash map insertion for the node ID and the timestamp syscall.

Add Edge

Time to insert a single edge and update both source and target adjacency lists.

Edge insertion is O(1) amortized for the edge itself, with O(degree) for adjacency list management. The higher absolute time compared to node insertion comes from updating two adjacency lists and validating both endpoints.

Graph Traversal (BFS)

Time for a breadth-first traversal from a single starting node. Graph has average degree 10 (5 outgoing, 5 incoming edges per node).

Traversal time depends on the number of nodes visited, which grows exponentially with depth (bounded by graph size and degree). The visited-set check (hash set lookup) is the primary cost per node.

Similarity Search

Brute-force cosine similarity search across all 128-dimensional feature vectors. Returns top-k results.

Similarity search is O(N * D) where N is node count and D is vector dimension. The contiguous vector layout enables SIMD auto-vectorization -- the compiler generates NEON instructions on ARM that process 4 floats per cycle. The top-k selection adds minimal overhead (binary heap, O(N log k)).

At 100K nodes, the cluster map index (when enabled) reduces search to approximately 15-20 ms by scanning only relevant clusters.

File Write

Time to serialize the complete graph to a .amem file, including LZ4 content compression and vector block construction.

Write time is dominated by LZ4 compression of the content block and sequential writes. The format's sequential layout (no random seeks during write) maximizes throughput.

File Read

Time to deserialize a .amem file into the in-memory graph, including LZ4 decompression.

Read performance benefits from LZ4's fast decompression (>3 GB/s) and the sequential file layout. Throughput increases at larger sizes because the fixed overhead (header parsing, allocation) is amortized.

Memory-Mapped Read (MmapReader)

Time to open a file and access a single random node via memory-mapped I/O.

Memory-mapped access avoids reading the entire file upfront. Node access is a direct pointer dereference after the initial page fault. This is ideal for applications that read a small subset of nodes from a large brain.

Comparison Context

These benchmarks are intended for understanding AgenticMemory's performance profile. Direct comparisons with other systems require careful methodology because they solve different problems.

Key architectural differences from vector databases:

• AgenticMemory is an embedded library, not a client-server system. There is no network round-trip.
• The graph structure (edges, traversal) is not present in pure vector databases.
• The binary file format is optimized for single-writer workloads, not concurrent multi-writer access.

Key architectural differences from graph databases (Neo4j, etc.):

• AgenticMemory is a file, not a server. No query language parsing, no transaction management.
• The fixed-size node records and contiguous layout are more cache-friendly than pointer-heavy graph representations.
• The trade-off is less flexibility: no ad-hoc queries, no schema migrations, no ACID transactions.

Reproducing Benchmarks

Prerequisites

# Rust toolchain
rustup update stable

# Clone and build
git clone https://github.com/anthropic/agentic-memory.git
cd agentic-memory

Running All Benchmarks

cargo bench

Results are written to target/criterion/ with HTML reports including statistical analysis, throughput charts, and regression detection.

Running Specific Benchmarks

# Only node operations
cargo bench -- add_node

# Only I/O benchmarks
cargo bench -- file_write
cargo bench -- file_read

# Only search benchmarks
cargo bench -- similarity_search

Generating a Report

cargo bench -- --save-baseline my_hardware

The HTML report at target/criterion/report/index.html includes:

• Distribution plots for each benchmark
• Mean, median, and standard deviation
• Throughput calculations
• Change detection vs. previous runs

Custom Graph Sizes

The benchmarks accept environment variables to control graph size:

BENCH_NODES=50000 BENCH_EDGES=250000 cargo bench

Profiling

For detailed profiling, use cargo-flamegraph:

cargo install flamegraph
cargo flamegraph --bench core_benchmarks -- --bench

This generates an SVG flamegraph showing where time is spent during benchmark execution.

v0.2 Query Expansion Benchmarks

All v0.2 query types benchmarked on 100K-node synthetic graphs (300K edges, 3 edges/node average). Measured with Criterion (100 samples) except where noted.

All Query Types at 100K Nodes

Scaling from 10K to 100K Nodes

Performance Tiers

Queries divide into three tiers at 100K nodes:

• Interactive (<100 ms): BM25, hybrid, PageRank, degree, BFS, Dijkstra, belief revision, drift -- suitable for per-query use during conversations
• Periodic (1-60 s): Betweenness centrality, consolidation -- run once per session or on a schedule
• Offline (>60 s): Gap detection, analogical reasoning -- designed for batch analysis of large graphs; both complete in <3s at 10K nodes

BM25 Index Acceleration

The inverted index speedup grows with graph size because the fast path cost depends on posting list size (sub-linear in n) while the slow path is always O(n).