Goblin Core 100k List Benchmark

Generated on a dedicated benchmark host at 2026-07-16 19:21:14 UTC.

Summary

goblin-resp-tcp leads 8 of 8 fixed-command rows, reaches 1.99x the fastest incumbent on middle-list LINDEX, population is 1.4% behind the fastest incumbent, and uses 25.35 RSS-delta bytes/item. goblin-sbe-ring leads 8 of 8 fixed-command rows, reaches 3.29x the fastest incumbent on middle-list LINDEX, population is 1475.1% ahead of the fastest incumbent, and uses 26.05 RSS-delta bytes/item. goblin-pma-resp-tcp leads 8 of 8 fixed-command rows, reaches 2.52x the fastest incumbent on middle-list LINDEX, population is 46.7% behind the fastest incumbent, and uses 27.85 RSS-delta bytes/item. goblin-resp-tcp is the leanest key representation at 17.16 accounted bytes/item versus 18.14 from the leanest incumbent's key-level counter. The leanest incumbent uses 21.42 RSS-delta bytes/item. TCP compound rows use the Python RESP pipeline; ring rows use the native C++ SBE client at the same pipeline depth. Fixed TCP rows use redis-benchmark.

Method

• 100,000 distinct 16-byte values in one list.
• Population: multi-value RPUSH batches of 128. RESP/TCP and SBE/ring both use pipeline depth 256.
• Population measures command ingestion, not Goblin Core native snapshot restoration; native restore reconstructs each list in one bulk operation and uses the compatible raw-copy accelerator when present.
• Fixed-command rates: 200,000 requests and one client. RESP/TCP uses pipeline depth 256 and the median of 3 redis-benchmark runs. SBE/ring uses the median of 3 native C++ runs at the same pipeline depth.
• Compound rates keep the list length constant. TCP engines use the existing RESP pipeline client; the ring row uses the native typed SBE client.
• Transport matrix: Goblin Core is measured as goblin-resp-tcp and goblin-sbe-ring; every incumbent is measured over RESP/TCP. No UDS row is included. The ring row uses a 2mb request and reply ring.
• Linux affinity: server core 2, client/load-generator core 3 (-1 means unpinned). Ring client and server must not share a core.
• Goblin implementation engines use their qualified command family (goblin-pma becomes GOBLIN.PMA.*); goblin exercises the selected standard aliases.
• Redis and Valkey use benchmarks/redis-parity.conf; Dragonfly uses one proactor thread for single-core parity. The intended target is a modest single-core memory server; the quiet benchmark host is a 64-core machine. Engines run one at a time.
• mini-redis-go runs as an external TCP server with GOMAXPROCS=1, AOF disabled, and metrics disabled. Unsupported commands are shown as n/a, not timed error replies.
• RSS is read from the launched server PID: mini-redis-go uses ps -o rss=, while the other engines use Linux /proc/<pid>/status as VmRSS + HugetlbPages. No server-reported RSS field is used. INFO used_memory and MEMORY USAGE are independent corroborating counters; RSS/INFO deltas subtract the empty-server baseline.
• Per-key bytes are MEMORY USAGE where an incumbent exposes it and GOBLIN.MEMORY total_allocated_bytes on Goblin Core. mini-redis-go exposes neither INFO memory nor MEMORY USAGE, so its RSS is the cross-engine memory measurement.
• Incumbents are exercised strictly as black-box RESP servers; their source code is not inspected.

Population

Operations

Logical operations per second. Fixed TCP commands use redis-benchmark; ring commands use the native C++ SBE client. Compound rows count a two-command pair as one logical operation.

Memory After Population

Memory After Operations

Goblin List Internals

Tested Servers

• goblin-resp-tcp
• goblin-sbe-ring
• goblin-pma-resp-tcp
• redis-7.2.4
• redis-8.8
• valkey-9.1
• dragonfly
• mini-redis-go-55178df