Repository files navigation

A variable size buffer pool for go.

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

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 theBufferPool more space efficient than a plainsync.Pool when used in situations where data size may vary over an arbitrary range.
2. Buffer: a buffer compatible withbytes.Buffer but backed by aBufferPool. Unlikebytes.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.

• 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).

• Can leak memory contents. Unlike the go GC, wedon'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.

PRs are welcome!

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

MIT © Protocol LabsBSD © The Go Authors

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