https://github.com/libp2p/go-buffer-pool
https://github.com/libp2p/go-buffer-pool
Last synced: about 1 year ago
JSON representation
- Host: GitHub
- URL: https://github.com/libp2p/go-buffer-pool
- Owner: libp2p
- License: mit
- Created: 2017-12-20T21:16:03.000Z (over 8 years ago)
- Default Branch: master
- Last Pushed: 2025-03-29T08:32:21.000Z (about 1 year ago)
- Last Synced: 2025-04-07T10:17:41.189Z (about 1 year ago)
- Language: Go
- Homepage:
- Size: 67.4 KB
- Stars: 80
- Watchers: 21
- Forks: 17
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
go-buffer-pool
==================
[](https://protocol.ai)
[](https://libp2p.io/)
[](https://webchat.freenode.net/?channels=%23libp2p)
[](https://codecov.io/gh/libp2p/go-buffer-pool)
[](https://travis-ci.org/libp2p/go-buffer-pool)
[](https://discuss.libp2p.io)
> A variable size buffer pool for go.
## Table of Contents
- [About](#about)
- [Advantages over GC](#advantages-over-gc)
- [Disadvantages over GC:](#disadvantages-over-gc)
- [Contribute](#contribute)
- [License](#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](https://github.com/RichardLitt/standard-readme) specification.
## License
MIT © Protocol Labs
BSD © The Go Authors
---
The last gx published version of this module was: 0.1.3: QmQDvJoB6aJWN3sjr3xsgXqKCXf4jU5zdMXpDMsBkYVNqa