Repository navigation
Consider adding ArraySegment support to ByteArrayUnpacker #289
Description
Today the ByteArrayUnpacker supports passing in a byte[] or byte[] and startOffset but it doesn't support limiting the unpacker's view of the array (e.g. there's no way to pass in a count). This works fine if I'm reading elements in a specific order and never fear going into other data that might be in the array. But, if I wanted to write a generic reader loop over the unpacker, I could end up reading other data from the array which was never intended for the Unpacker.
Ideally MsgPack-Cli would support passing an ArraySegment<byte> and eventually a Memory<byte>/Span<byte> (new in .NET but not RTM yet) so we could limit the view of the array from the unpacker.
Activity
yfakariya commentedon Mar 26, 2018
Thank you for feedback!
I have two question about this:
ArraySegment<byte>required even whenMemory<byte>andSpan<byte>are released?ArraySegment<byte>based implementation in a99bfed because it hurt performance. I guess it was occurred by size ofArraySegment<byte>struct. Do you have any idea?davidfowl commentedon Mar 26, 2018
No,
Memory<byte>orSpan<byte>would be better (when they are released).It could have been struct copies, you could try using the C# in syntax (C# 7.2 or 7.3?) to reduce those copies. Alternatively, you can add an
int countparameter to the array overload and it would suffice until those other types are widely available.chkr1011 commentedon Apr 23, 2019
I also need that overload. In my application I have several buffer but I always need to create a copy from some ArraySegments using ToArray which is allocating useless memory.
I also tried to use the Unpacker with the original array and offset 0. But the Unpacker is not able to deserialize the object (returns null). Maybe because the buffer is 4k and there is no length property available!?
yfakariya commentedon Apr 23, 2019
I see, self managed buffer scenario is absolutely good point to start.