zbuf 0.1.2

“Zero-copy” string and bytes buffers
Documentation
  • Coverage
  • 100%
    7 out of 7 items documented2 out of 2 items with examples
  • Size
  • Source code size: 81.44 kB This is the summed size of all the files inside the crates.io package for this release.
  • Documentation size: 2.03 MB This is the summed size of all files generated by rustdoc for all configured targets
  • Ø build duration
  • this release: 10s Average build duration of successful builds.
  • all releases: 10s Average build duration of successful builds in releases after 2024-10-23.
  • Links
  • Repository
  • crates.io
  • Dependencies
  • Versions
  • Owners
  • github:servo:cargo-publish SimonSapin

BytesBuf and StrBuf are “zero-copy”[1] buffers. They are semantically equivalent to Vec<u8> and String respectively (they derefence to &[u8] / &str, they are mutable and growable), but have optimizations that minimize the number of data copies and memory allocations required.

  • Inline buffers (a.k.a. small string optimization): Small buffers (up to 15 bytes on 64-bit platforms, up to 11 bytes on 32-bit platforms) are stored inline and do not allocate heap memory.
  • Reference counting: Multiple buffers can refer to the same reference-counted heap allocation. Cloning a buffer is cheap: it never allocates, at most it increments a reference count.
  • Slicing without borrowing: A buffer can be a sub-slice of another without being tied to its lifetime, nor allocating more heap memory.

Limitations:

  • Up to 4 GB: To keep the std::mem::size_of() of buffers more compact, sizes are stored as u32 internally. Trying to allocate more than 4 gigabytes will panic, even on 64-bit platforms with enough RAM available.
  • No cheap conversions with standard library vectors: In heap-allocated buffers the data is stored next to a header of metadata. Conversion to or from Vec<u8> / Box<[u8]> / String / Box<str> therefore necessarily goes through slices and incurs and data copy and memory allocation.