Motivation:
We need a simple API to efficiently iterate a buffer.
We've used the ByteProcessor so far, and while its internal iteration API is simple, it looses some efficiency by forcing code to only consider one byte at a time.
Modification:
The ByteIterator fills the same niche as the ByteProcessor, but uses external iteration instead of internal iteration.
This allows integrators to control the pace of iteration, and it makes it possible to expose methods for consuming bytes in bulk; one long of 8 bytes at a time.
This makes it possible to use the iterator in SIMD-Within-A-Register, or SWAR, data processing algorithms.
Result:
We have a ByteIterator for efficiently processing data within a buffer.
Motivation:
We'd like to separate the API and the implementation, so we can make other implementations in the future.
This will allow us to deliver the API changes without the new MemorySegment implementation.
Modification:
The MemoryManager interface abstracts away the implementation details of the concrete buffer type, and how to allocate and deallocate them.
Result:
Knowledge of MemorySegments are now confined to just the MemSegBuf and MemoryManager implementation classes.
The intent is that this will hide the BBuf implementation in the long run.
For the time being, it highlights an issue with the Rc family of types and their generics, and specifically how they are complicated to compose with other interfaces.
Motivation:
We want to be able to compare the performance of the existing ByteBuf implementation, and the new MemorySegment based BBuf.
Modification:
Copy the existing access benchmark for ByteBuf, and modify the copy to use the new BBuf instead.
Result:
We are able to get our first benchmark runs with BBuf.
The cost of accessing memory in BBuf is roughly twice that of the comparable ByteBuf implementations.
I think we'll need to improve this if we want BBuf to be a viable path forward.
