Available implementations
When to use each
Slice (recommended default)
The slice-backed implementation is the fastest option in almost every benchmark, particularly when you supply a size hint to preallocate the backing array. Start here unless you have a specific reason to choose otherwise.- Best throughput for both Enqueue/Push and Dequeue/Pop
- Preallocating with a size hint eliminates most allocations in the steady state
- Consistent top-ranked performance across Go 1.18 and Go 1.24, on both amd64 and arm64
List
A doubly-linked list that allocates one node per element. Avoids resizing the backing structure when you do not know the capacity in advance, but allocation overhead per operation is significantly higher than a preallocated slice.- No amortized resize penalty when the working set is unbounded
- Higher per-operation allocation cost (heap node per element)
- A good fallback if you genuinely cannot estimate capacity
ListWithInternalPool (ListIP)
A linked list that recycles nodes using an internal pool. This reduces allocation pressure compared to a plain List, and comes close to Slice performance in several benchmarks—but never surpasses it.
- Better than plain List; useful when you want to avoid
sync.Pool - Still slower than Slice with a size hint
ListWithSyncPool (ListSP)
A linked list that recycles nodes using sync.Pool. In practice this is the slowest option across all benchmarks and architectures.
The sizeHint parameter
Every constructor accepts a sizeHint int argument. When you pass a positive value, the implementation preallocates backing storage for that many elements, avoiding allocations until the collection grows beyond that capacity.
Creating each variant
Queue
Stack
OrderedMap
Only the slice-backed implementation is available. Passstable: true for in-place updates (highest throughput), or stable: false for recency-based ordering (LRU-style).