What Goblin Core proves about performance work

Performance work should leave evidence behind. Goblin Core is one example of what that evidence can look like: not a vague claim that a system is “fast,” but measurements tied to a workload, a transport, and a machine.

The current headline numbers are:

• 51 bytes of RSS per sorted-set member at four million members.
• 14.3 billion real Lichess rating updates replayed.
• 220 nanoseconds for a single-element shared-memory request and reply.
• 392,000 ZADD operations per second on one core.

Those numbers describe different parts of the system. They should not be compressed into one universal speed claim.

Memory is a data-structure decision

At four million sorted-set members, Goblin Core uses 51 bytes of resident memory per member. That result comes from packed arenas and compact Swiss-table indexes instead of a graph of separately allocated objects.

The useful lesson is broader than Redis compatibility: when memory cost grows with millions of tiny objects, allocation strategy and data layout are often the product architecture. Treating them as implementation details can become very expensive.

Throughput needs a realistic history

The Lichess replay runs 14.3 billion real rating updates in chronological order and checks the result against Redis member for member. A long, real history exercises behavior that a small synthetic loop can miss: changing set sizes, repeat updates, ranking churn, and the cumulative effects of the storage design.

Latency includes the round trip

The 220 ns result is a synchronous, unpipelined request and reply for a one-field HSET or one-member ZADD over shared-memory SBE rings. The client and server are pinned to separate cores on a Threadripper PRO 5995WX, and the server busy-polls.

That context matters. The result shows what is possible when the kernel is removed from the hot path and a core is deliberately owned by the service. It is not a promise that an ordinary networked deployment will respond in 220 ns.

A benchmark should make the trade visible

The single-core ZADD result measures 392,000 operations per second. Together with the latency and memory numbers, it gives a more useful picture than any one result alone: how much work a core completes, how quickly one request returns, and how much memory the data consumes.

That is the standard Goblin Reactor brings to client work. First define the workload and the outcome that matters. Then measure the existing system, isolate the cost, build the smallest credible optimization, and state the tradeoffs alongside the result.

The full benchmark methodology and current results live at goblin-core.dev.