I've been working on nexus-slab, part of the Nexus project - a collection of non-general-purpose but high-performance primitives for high performance systems.

The problem: Standard Vec-backed slabs have bimodal p999 latency. When capacity is exceeded, Vec reallocates and copies all existing data. At scale, this copy dominates - you'll see p999 jump from ~30 cycles to 2400+ cycles depending on whether a realloc lands in your measurement window.

The tradeoff:

You pay ~2 cycles on median to eliminate reallocation spikes.

How it works: Independent page-aligned slabs that grow without copying existing data. Two-level freelist (slab → slot) with LIFO reuse for cache locality.

This is probably NOT for you if:

• Your slab stays "small"
• Tail latency isn't a huge concern
• The slab crate works fine for your use case

This might be for you if:

• You're building order books, matching engines, session managers, or game servers
• You've profiled and see reallocation spikes in your p99/p999
• Predictable worst-case matters for your SLAs
• You have large slabs

crates.io | GitHub

Feedback wanted:

1. Does the API surface make sense?
2. Any workloads you'd want benchmarked?
3. Missing features that would block adoption?

2 posts - 2 participants

Read full topic