Skip to content

Implement ReadSpan/WriteSpan methods in UnmanagedMemoryAccessor #118296

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

lostromb
Copy link

@lostromb lostromb commented Aug 1, 2025

THIS IS JUST A PROOF OF CONCEPT PULL REQUEST, IT DOESN'T HAVE TESTS OR ANYTHING, DON'T MERGE IN ITS CURRENT STATE

The current UnmanagedMemoryAccessor implementation only has the ability to read/write arrays using a slow struct marshalling loop, despite the fact that the underlying SafeBuffer already has a much more performant ReadSpan/WriteSpan implementation. This change adds a shim method to UnmanagedMemoryAccessor which allows it to read/write byte span data, using a similar signature to Read/WriteArray but with the performance of Span.

This change is specifically intended for users of MemoryMappedFiles to get the fastest performance with byte block data without requiring them to use unsafe code.

See dotnet issue #107148

The current UnmanagedMemoryAccessor only has the ability to read/write arrays using a slow struct marshalling loop, despite the fact that the underlying SafeBuffer now has a much more performant ReadSpan/WriteSpan implementation. This change adds a shim method to UnmanagedMemoryAccessor which allows it to read/write byte span data with a similar signature to Read/WriteArray and the performance of Span.
@github-actions github-actions bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Aug 1, 2025
@dotnet-policy-service dotnet-policy-service bot added the community-contribution Indicates that the PR has been added by a community member label Aug 1, 2025
@lostromb
Copy link
Author

lostromb commented Aug 1, 2025

@dotnet-policy-service agree company="Microsoft"

(well I guess I'm not an MS employee anymore so this is just on behalf of myself)

@teo-tsirpanis
Copy link
Contributor

Hello, according to the process, Pull Requests that add new APIs must be opened after their approval, which means that I have to close this. Feel free to open a new PR after that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
community-contribution Indicates that the PR has been added by a community member needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants