Repository navigation
Consider adding ArraySegment support to ByteArrayUnpacker #289
Description
Activity
Thank you for feedback!
I have two question about this:
- Is
ArraySegment<byte>required even whenMemory<byte>andSpan<byte>are released? - In fact, I removed
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?
- Is
Is ArraySegment required even when Memory and Span are released?
No,
Memory<byte>orSpan<byte>would be better (when they are released).In fact, I removed ArraySegment based implementation in a99bfed because it hurt performance. I guess it was occurred by size of ArraySegment struct. Do you have any idea?
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.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!?
I see, self managed buffer scenario is absolutely good point to start.
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 aMemory<byte>/Span<byte>(new in .NET but not RTM yet) so we could limit the view of the array from the unpacker.