โ† cognition

Allocate Once. Pool Everywhere.

Memory allocation is not free. It's one of the most expensive habits modern systems hide.

Most systems don't notice. They allocate constantly, clean up later, and call it normal.

It isn't.

The Default Mistake

allocate โ†’ use โ†’ discard โ†’ repeat

Over and over. Each allocation touches the heap, pressures the GC, fragments memory, introduces latency you don't control.

The system works harder managing memory than doing useful work.

The Hidden Cost

Allocations don't just cost time. They create unpredictability.

GC pauses (stop-the-world)
Allocator contention (malloc / heap locks)
Cache churn
Memory fragmentation

Everything looks fineโ€ฆ until it doesn't. Then you get random latency spikes, throughput collapse under load, behaviour that can't be reproduced locally.

You didn't remove the cost. You deferred it.

Stop-The-World Reality

Garbage collection is not magic. At some point, it stops everything.

Threads pause
Work halts
Latency spikes

You don't control when it happens. You only control how much you trigger it.

More allocation โ†’ more pressure โ†’ more pauses.

malloc Isn't Free Either

Even without GC, allocation still hurts.

Heap locks
Syscalls
Page faults
NUMA effects

malloc looks cheap in isolation. Under load, it becomes a bottleneck.

Hidden Leaks

The worst part isn't obvious leaks. It's the subtle ones.

Forgotten returns to pool
Long-lived references
"Temporary" buffers that become permanent
Allocation patterns that slowly grow over time

No crash. Just gradual degradation. The system rots quietly.

The Inversion

Allocate once. Reuse everywhere.

Buffers. Objects. Working memory. All pooled. All reused. Nothing new on the hot path unless absolutely necessary.

Memory as Infrastructure

Memory stops being disposable. It becomes infrastructure.

You don't create it. You provision it.

Take from pool โ†’ use โ†’ return

No churn. No surprises.

Stability Over Time

Pooling gives you:

Consistent latency
Minimal GC pressure
Stable memory footprint

The system stops spiking. It just runs.

Spans Make It Work

This only works because of the underlying model: everything is (ptr, len).

You don't need new objects. You need new views.

Slice. Reuse. Reinterpret.
No copies. No allocations.

The Pattern

Allocation is a failure to plan ahead.

If you understand your system โ€” sizes are predictable, concurrency is bounded, pressure points are known โ€” then you allocate once. And reuse.

The Frame

Bad System

Builds a new tool every time.
Throws it away.

Good System

Has a rack of tools.
Reuses them endlessly.

Same work. Different universe.

Why This Matters

This isn't micro-optimisation. It's the difference between smooth systems and spiky ones. Predictable vs chaotic. Scalable vs fragile.

Spans โ†’ no copies
Constraints โ†’ less work
Alignment โ†’ fewer executions
Pooling โ†’ no churn

If you're allocating on the hot path, you're trading performance for entropy.