[wasm] Fast-track ASCII/UTF8 conversion in wasm #51310
Conversation
|
Tagging subscribers to 'arch-wasm': @lewing Issue Details
|
|
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
| @@ -19,8 +19,10 @@ public static OperationStatus TranscodeToUtf16(byte* pInputBuffer, int inputLeng | |||
| Debug.Assert(outputCharsRemaining >= 0, "Destination length must not be negative."); | |||
| Debug.Assert(pOutputBuffer != null || outputCharsRemaining == 0, "Destination length must be zero if destination buffer pointer is null."); | |||
|
|
|||
| var input = new ReadOnlySpan<byte>(pInputBuffer, inputLength); | |||
| var output = new Span<char>(pOutputBuffer, outputCharsRemaining); | |||
| // try fast-tracking ASCII first before falling back to the standard loop | |||
There was a problem hiding this comment.
This means that this is going to fully fix the regression for ASCII-only payloads. The regression is still going to be there to varying degress once the payload contains non-ASCII characters. What do the perf numbers look like for non-ASCII payloads?
There was a problem hiding this comment.
What if we marked Rune.DecodeUtf8 and Rune.DecodeUtf16 as aggressive-inlining, at least on wasm? Those methods each have some amount of error handling logic, where they'll try to figure out how to recover from any invalid data. But these immediate callers don't care about recovering from invalid data. These callers simply want to halt when invalid data is encountered. If we inline those methods, in theory the error recovery logic should be elided because it triggers the if (not success) { break; } block. That might result in a perf improvement, but I don't know offhand what such an improvement might look like.
|
Closing this draft as we are going to revert the previous change for P4 (#51379) |
ghost
locked as resolved and limited conversation to collaborators
No description provided.