I believe that in .NET 2.0 (due for release q3 2017*) the Span<T> will allow efficient access to parts of an array of bytes.
We have a scenario where we read files of 100MB that are made up of a repeating pattern of meta data followed by LZ4 MessagePack Serialized content.
When reading the files, we currently copy the content to its own array and pass that to LZ4MessagePackSerializer.Deserialize.
I believe we would reduce our GC pressure considerably if we were able to use the Span<T> type.
Alternatively offset and length parameters could be added to the Deserialize method.
A further alternative is that and overload of Deserialize takes ArraySegment<T> as its argument.
This appears to be considered as a feature (#60), but I thought I would raise an issue so that it can be tracked.
Also thanks for the library. We have seen some massive speed improvements adopting it.
Supporting links
I believe that in .NET 2.0 (due for release q3 2017*) the
Span<T>will allow efficient access to parts of an array of bytes.We have a scenario where we read files of 100MB that are made up of a repeating pattern of meta data followed by LZ4 MessagePack Serialized content.
When reading the files, we currently copy the content to its own array and pass that to
LZ4MessagePackSerializer.Deserialize.I believe we would reduce our GC pressure considerably if we were able to use the
Span<T>type.Alternatively
offsetandlengthparameters could be added to theDeserializemethod.A further alternative is that and overload of
DeserializetakesArraySegment<T>as its argument.This appears to be considered as a feature (#60), but I thought I would raise an issue so that it can be tracked.
Also thanks for the library. We have seen some massive speed improvements adopting it.
Supporting links