If you have a place to write, then it's not zero allocation. You did an allocation.
And usually if you want maximum performance, buffered read is the way to go, which means you need a write slab allocation.
If you have a place to write, then it's not zero allocation. You did an allocation.
And usually if you want maximum performance, buffered read is the way to go, which means you need a write slab allocation.
> If you have a place to write, then it's not zero allocation. You did an allocation.
Where did that allocation happen? You can write into the buffer you're reading from, because the replacement data is shorter than the original data.
You have a read buffer and somewhere where you have to write to.
Even if we pretend that the read buffer is not allocating (plausible), you will have to allocate for the write source for the general case (think GiB or TiB of XML or JSON).
> You have a read buffer and somewhere where you have to write to.
The "somewhere you have to write to" is the same buffer you are reading from.
Not if you are doing buffered reads, where you replace slow file access with fast memory access. This buffer is cleared every X bytes processed.
Writing to it would be pointless because clears obliterate anything written; or inefficient because you are somehow offsetting clears, which would sabotage the buffered reading performance gains.
Maybe I missed it, but ITT we were talking about C buffers, not buffered reads.
I thought we were talking about high performance parsing. Of which buffered reads are one. Other is loading entire document into mutable memory, which also has limitations.