ZeroCopyReader: chunk consolidation as a future optimization

[SeanTAllen]

ZeroCopyReader: chunk consolidation as a future optimization

Follow-up from #66 (Zero-copy decoding).

Context

The ZeroCopyReader design uses multi-chunk storage: chunks are appended as-is, zero-copy reads succeed when the requested range falls within a single chunk, and a copy fallback handles cross-chunk spans. This is the initial implementation approach.

The consolidation alternative

Instead of keeping chunks separate, copy all appended data into a single contiguous buffer on append(). This guarantees every block() call can use trim for zero-copy — no cross-chunk fallback needed.

append(data) -> copy into single buffer (one copy on input)
block(len)   -> trim(offset, offset + len) (always zero-copy)

Tradeoffs

Pros:

• Every read is guaranteed zero-copy. No fallback path.
• Simpler block() implementation — no chunk-spanning logic.
• Better for workloads that decode many values per appended chunk, amortizing the input copy.

Cons:

• One copy on every append(), even if the data would have been contiguous anyway.
• Requires solving a val freezing pattern: trim needs val, but appending needs mutability. The buffer must be frozen to val before reads and a new mutable buffer started for subsequent appends. This adds complexity.
• Worse for workloads where few values are decoded per chunk — the input copy isn't amortized.

When to revisit

If profiling shows the cross-chunk copy fallback in multi-chunk mode is hitting frequently enough to affect performance, consolidation becomes worth exploring. Until then, multi-chunk is simpler and avoids the val freezing complexity.