libp2p / go-buffer-pool

go-buffer-pool

A variable size buffer pool for go.

Table of Contents

• About
  • Advantages over GC
  • Disadvantages over GC:
• Contribute
• License

About

This library provides:

1. BufferPool: A pool for re-using byte slices of varied sizes. This pool will always return a slice with at least the size requested and a capacity up to the next power of two. Each size class is pooled independently which makes the BufferPool more space efficient than a plain sync.Pool when used in situations where data size may vary over an arbitrary range.
2. Buffer: a buffer compatible with bytes.Buffer but backed by a BufferPool. Unlike bytes.Buffer, Buffer will automatically "shrink" on read, using the buffer pool to avoid causing too much work for the allocator. This is primarily useful for long lived buffers that usually sit empty.

Advantages over GC

• Reduces Memory Usage:

  • We don't have to wait for a GC to run before we can reuse memory. This is essential if you're repeatedly allocating large short-lived buffers.

• Reduces CPU usage:

  • It takes some load off of the GC (due to buffer reuse).
  • We don't have to zero buffers (fewer wasteful memory writes).

Disadvantages over GC:

• Can leak memory contents. Unlike the go GC, we don't zero memory.
• All buffers have a capacity of a power of 2. This is fine if you either expect these buffers to be temporary or you need buffers of this size.
• Requires that buffers be explicitly put back into the pool. This can lead to race conditions and memory corruption if the buffer is released while it's still in use.

Contribute

PRs are welcome!

Small note: If editing the Readme, please conform to the standard-readme specification.

License

MIT © Protocol Labs BSD © The Go Authors

---

The last gx published version of this module was: 0.1.3: QmQDvJoB6aJWN3sjr3xsgXqKCXf4jU5zdMXpDMsBkYVNqa