[API Proposal]: Add read/write span methods to UnmanagedMemoryAccessor

[masonwheeler]

Background and motivation

#27831 added ReadSpan<T> and WriteSpan<T> methods to SafeBuffer, with the explicit intent of surfacing them in UnmanagedMemoryAccessor in a later PR:

The motivation for this is for a later API proposal to add the same methods to UnmanagedMemoryAccessor which will work for memory mapped views.

This was merged 4 years ago, but the later PR appears to have never happened.

API Proposal

Add the following methods to UnmanagedMemoryAccessor:

+        public void ReadSpan<T>(ulong byteOffset, Span<T> buffer) where T : struct
+        public void WriteSpan<T>(ulong byteOffset, ReadOnlySpan<T> data) where T : struct

Their implementations would be similar to the existing ReadArray<T> and WriteArray<T> methods, doing verification and then calling the corresponding methods on _buffer.

API Usage

string text = "Hello, World!";
myMemoryMappedViewAccessor.WriteSpan(MY_OFFSET, text.AsSpan());

Alternative Designs

No response

Risks

None that I can see; the underlying APIs were developed specifically for this purpose.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

[lostromb]

I came here to post this. This seems like an almost trivially simple use case to implement that I'm surprised it hasn't been done yet, even with pre-span byte[] array, int offset, int count style function signatures.

The current runtime ReadArray<T> and WriteArray<T> internally run a struct marshaller iterating over every single array index, which for the case of byte, the marshaller does nothing except prevent the use of CPU-optimized mem copies using SIMD or equivalent., making the copies run (by my measurement) about 30x slower than they should be.

Working around this currently requires code similar to:

unsafe
{
    byte* ptr = null;
    fileAccessor.SafeMemoryMappedViewHandle.AcquirePointer(ref ptr);
    new Span<byte>(ptr + readOffset, length).CopyTo(buf.AsSpan(writeOffset, length));
    fileAccessor.SafeMemoryMappedViewHandle.ReleasePointer();
}

Heck, I might just create the pull request myself.....

[aka-nse]

@masonwheeler
Why did you choice ulong for byte offset parameter in your proposal?
Other APIs in UnmanagedMemoryAccessor employs long type to specify position, and ulong is CLS incompliant.

[masonwheeler]

@aka-nse It's been long enough now that I don't remember. long works just fine too.

[RobSwDev]

Any news on this? It's marked as "needs-further-triage", but from my (admittedly naive) point of view, it's a relatively simple win.