Skip to content

StringMarshaller optimizations #69035

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.

Sign up for GitHub

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

Jump to bottom
Merged
jkotas merged 4 commits into from
May 11, 2022
Merged

StringMarshaller optimizations #69035

jkotas merged 4 commits into from
May 11, 2022

Conversation

@jkotas
Copy link
Member

@jkotas jkotas commented May 8, 2022

  • Make the StringMarshallers smaller. They do not need to store the full stackallocated Span.
  • Use the stack allocated buffer more often.
  • Other fixes for consistency

@ghost ghost assigned jkotas May 8, 2022
@ghost
Copy link

ghost commented May 8, 2022

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

@ghost
Copy link

ghost commented May 8, 2022

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

Issue Details
  • Make the StringMarshallers smaller. They do not need to store the full stackallocated Span.
  • Use the stack allocated buffer more often.
  • Other fixes for consistency
Author: jkotas
Assignees: jkotas
Labels:

area-System.Runtime.InteropServices, new-api-needs-documentation
Milestone: -

jkotas
jkotas commented May 8, 2022
View reviewed changes
...ystem.Private.CoreLib/src/System/Runtime/InteropServices/Marshalling/Utf8StringMarshaller.cs Outdated
Copy link
Member Author

@jkotas jkotas May 8, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes the marshaller faster for ascii strings of lengths between 85 and 256. The cost of calculating the exact buffer length is less than the cost of going through the Alloc/Free path.

jkotas
jkotas commented May 8, 2022
View reviewed changes
...ystem.Private.CoreLib/src/System/Runtime/InteropServices/Marshalling/Utf8StringMarshaller.cs Outdated
Copy link
Member Author

@jkotas jkotas May 8, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The built-in marshallers use exact-sized buffers for some cases and conservatively-sized buffer for other cases. For example, check

runtime/src/coreclr/System.Private.CoreLib/src/System/StubHelpers.cs

Lines 94 to 96 in 041933f

// Otherwise we use a slower "2-pass" mode where we first marshal the string into an intermediate buffer
// (managed byte array) and then allocate exactly the right amount of unmanaged memory. This is to avoid
// wasting memory on systems with multibyte character sets where the buffer we end up with is often much
.

I think we should just do the exact-sized buffers everywhere. The long strings are rare. When the long strings do show up, the 3x over-allocation for them feels like a lot.

Copy link
Member Author

@jkotas jkotas May 8, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am wondering whether it would make sense to fix the Marshal methods to do the exact-sized allocations as well.

@jkotas
Copy link
Member Author

jkotas commented May 8, 2022

This reduces the utf8 string marshaling overhead for a method with a single "Hello" argument by about 10%.

#69031 has suggestion for how this can be optimized further.

@jkotas jkotas requested a review from MichalStrehovsky as a code owner May 10, 2022 05:09
jkotas and others added 4 commits May 10, 2022 18:29
@jkotas
StringMarshaller optimizations
e0e8998 
- Make the StringMarshallers smaller. They do not need to store the full stackallocated Span.
- Use the stack allocated buffer more often.
- Other fixes for consistency
@jkotas
Improve fast path
55ce215
@jkotas
Delete Utf16StringMarshaller constructor that takes caller allocated …
4b9f864 
…buffer
@jkotas @AaronRobinsonMSFT
Update src/libraries/System.Private.CoreLib/src/System/Runtime/Intero…
e0daa5d 
…pServices/Marshalling/Utf16StringMarshaller.cs

Co-authored-by: Aaron Robinson <arobins@microsoft.com>
@jkotas jkotas force-pushed the string-marshaling branch from 98397db to e0daa5d Compare May 11, 2022 01:32
@jkotas jkotas mentioned this pull request May 11, 2022
Closed
2 tasks
@jkotas jkotas merged commit 130ef3c into dotnet:main May 11, 2022
@jkotas jkotas deleted the string-marshaling branch May 11, 2022 15:41
@jkotas jkotas added the tenet-performance Performance related issue label May 12, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Jun 11, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

@stephentoub stephentoub stephentoub approved these changes

@AaronRobinsonMSFT AaronRobinsonMSFT AaronRobinsonMSFT approved these changes

@elinor-fung elinor-fung Awaiting requested review from elinor-fung

@MichalStrehovsky MichalStrehovsky Awaiting requested review from MichalStrehovsky

+1 more reviewer

@f2bo f2bo f2bo left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

@jkotas jkotas

Labels

area-System.Runtime.InteropServices new-api-needs-documentation tenet-performance Performance related issue

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@jkotas @f2bo @stephentoub @AaronRobinsonMSFT @elinor-fung