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