For many small stream writes, RecyclableMemoryStream is slower than other implementations about microsoft.io.recyclablememorystream HOT 4 OPEN

Thanks @sgorozco, this is in fact whats happening here, a BinaryWriter writes a lot of little chunks (e.g. int, byte, etc) for a OPC UA binary encoder. The Write implementation should only copy the small chunks into the buffer, keep two indexes (one for the actual buffer, one for the write pointer into the actual buffer). An overflow may split the write and allocates a new buffer or moves to the next buffer. Thats it. I would be interested to see why a division is necessary.

Update -- I checked:

--> GetBlockAndRelativeOffset uses a division.

I guess its a design decision to make write faster or the calculation of the position, or what to use as the source of truth.
My expectation were that the Write is almost as fast as the Write in the MemoryStream base class. Wishful thinking :-)

from microsoft.io.recyclablememorystream.

Yeah, the issue with lots of small writes is something that has come up a few times before. Unfortunately, it just wasn't optimized for that scenario. The workaround would be to operate directly on the buffer, but not all APIs will support that, and that does defeat the purpose of using a stream.

A way to fix this would be to change the source of truth for the current position. Currently, we store a long position, that we then convert to block/offset on every necessary operation, which involves, as you noted, two divisions. We could change this to track the block/offset instead, and then when we need the position, do the multiply+add, which should be much faster. Alternatively, we could just track both values and keep them in sync, but I suspect this doesn't offer any additional benefit (we'd be doing the multiply+add anyway, or a lot of individual adds).

I'd have to think about any negative performance ramifications (e.g., calling Position is much more expensive), but perhaps it's not so bad. I'll ponder it.

from microsoft.io.recyclablememorystream.

from microsoft.io.recyclablememorystream.

As an additional sidenote, turns out that in my JSONEncoder Tests where writing uses StreamWriter in contrary to BinaryWriter above, RecyclableMemoryStream outperforms all other stream implementations... this is currently our main use case so technically I'm a happy camper with the current implementation.

from microsoft.io.recyclablememorystream.