Skip to main content

Quick Start

Why Object Pooling?

In high-throughput scenarios (10k+ TPS), object allocation becomes a bottleneck:
  1. Memory allocation: Creating new objects is expensive
  2. Garbage collection: Many short-lived objects trigger GC
  3. Cache locality: Reused objects stay in CPU cache
Object pooling addresses these by reusing message objects.

Performance Impact

Benefits increase with message volume due to reduced GC pressure.

Usage Patterns

Basic Usage

Context Manager

Batch Processing

Thread Safety

The pool is thread-safe for concurrent access:

Pool Sizing

Choose pool size based on:
  1. Concurrency level: Number of messages processed simultaneously
  2. Message retention: How long messages are held before release
  3. Memory constraints: Each message ~1KB
Rule of thumb: pool_size = concurrent_workers * 2

Pool Exhaustion

When pool is exhausted, new objects are created (no blocking):

Monitoring

Best Practices

Do

Don’t

When to Use

Use pooling when:
  • Processing > 10k messages per second
  • Memory pressure is a concern
  • GC pauses are noticeable
Skip pooling when:
  • Processing < 1k messages per second
  • Messages need long-term storage
  • Simplicity is preferred

API Reference

See Core API Reference for complete API documentation.