Static Allocation, Constant Work: A Trick for Predictable Performance

In this post, the author discusses two techniques from TigerBeetle's TigerStyle guide for building systems with predictable performance and memory safety: static allocation and constant work. Static allocation means pre-allocating all memory at startup and rejecting requests beyond the limit, avoiding OOM kills and gray failures. Constant work means always processing a fixed set of objects, using neutral 'reserved' states instead of dynamic creation/destruction, which simplifies logic and improves cache locality. The author applies these to an order-matching engine example and notes they're not universal solutions.

Systems operating at capacity without strict limits fail catastrophically.
  1. mrkeen

    > TigerStyle: All memory must be statically allocated at startup. No memory may be dynamically allocated (or freed and reallocated) after initialization. This avoids unpredictable behavior that can significantly affect performance, and avoids use-after-free.

    Maybe maintaining an array of NULL-orders satisfies the letter of the "no dynamic allocation" law, but I'm not convinced it satisfies the spirit.

    Haven't you just written a buffer of NULL-orders, which you proceed to loan out to callers (i.e. "allocate" and "reallocate"?).

    Someone else's battle-hardened allocator might be slow or buggy, so you write your own as part of the business logic implementation?

  2. markus0

    I want to work more with systems that always abide by such strict constraints and style / design guides, but at the same time I feel like the reality of building software at scale is teams ending up working in subsystems that don’t consider the holistic operating model of the program. So even with best practices locally, the system as a whole ends up fragmented and inefficient, and strict global constraints therefore feel limiting.

  3. pjmlp

    Interesting how everyone keeps rediscovering 8 and 16 bit home computer programming techniques, after all these years, mostly I guess caused by the scripting languages for everything during the last two decades.

More from this day

2026-09-03