Using SearchValues in ContentDispositionHeaderValue#55039
Using SearchValues in ContentDispositionHeaderValue#55039amcasey merged 12 commits intodotnet:mainfrom
Conversation
|
Adding @amcasey as he has been reviewing the previous related PRs. |
|
To confirm, |
|
Sorry, I think we got our lines crossed. I know encoding is expected to be slower than no-encoding (by a variable amount), but it looks like encoding-after is slower than encoding-before? |
amcasey
left a comment
There was a problem hiding this comment.
The change looks generally correct, but I think the possible perf regression in the no-encoding case is worth revisiting.
|
Here is my latest run:
|
Updating current Encode5987 method to use SearchValues and IndexOfAny to encode the FileNameStar property. Adding unit tests and a benchmark to measure the before-after performance
2eadb69 to
7dc32d9
Compare
| builder.Append('%'); | ||
| builder.Append(HexUpperChars[(c & 0xf0) >> 4]); | ||
| builder.Append(HexUpperChars[c & 0xf]); | ||
| // Inspired by https://source.dot.net/#System.Private.CoreLib/src/libraries/System.Private.CoreLib/src/System/Text/Rune.cs TryEncodeToUtf8 |
There was a problem hiding this comment.
Not a fan of copying this code. How much would we lose if we just stackalloc byte[4] and called TryEncodeToUtf8 and looped over the result to write to the StringBuilder?
There was a problem hiding this comment.
Personally, I can live with the copy since it's an implementation of spec'd behavior. I don't think we'll get out of sync in a way that reduces correctness, but we could well fail to benefit from future perf wins. If there's a way around copying, that would be preferable, but I wouldn't block the PR for this. Having said that, I also wouldn't go ahead without @BrennanConroy's approval.
Co-authored-by: Günther Foidl <[email protected]>
amcasey
left a comment
There was a problem hiding this comment.
LGTM, subject to @BrennanConroy's approval.
| builder.Append('%'); | ||
| builder.Append(HexUpperChars[(c & 0xf0) >> 4]); | ||
| builder.Append(HexUpperChars[c & 0xf]); | ||
| // Inspired by https://source.dot.net/#System.Private.CoreLib/src/libraries/System.Private.CoreLib/src/System/Text/Rune.cs TryEncodeToUtf8 |
There was a problem hiding this comment.
Personally, I can live with the copy since it's an implementation of spec'd behavior. I don't think we'll get out of sync in a way that reduces correctness, but we could well fail to benefit from future perf wins. If there's a way around copying, that would be preferable, but I wouldn't block the PR for this. Having said that, I also wouldn't go ahead without @BrennanConroy's approval.
|
Thanks, @ladeak! |
Using SearchValues in ContentDispositionHeaderValue
Task of #46484
Description
Updating the current Encode5987 method to use SearchValues and IndexOfAny method during the encode of the FileNameStar property. Adding unit tests and a benchmark to measure the before-after performance.
Compared to the .NET runtime implementation a second
Span<char>is pooled becauseValueStringBuilderused by the .NET runtime is internal, henceEncoding.ASCII.GetCharsneeds a way to reference the chars passed to theStringBuilderPerformance Comparison:
BenchmarkDotNet=v0.13.0, OS=Windows 10.0.22631
12th Gen Intel Core i7-1255U, 1 CPU, 12 logical and 10 physical cores
.NET SDK=9.0.100-preview.4.24201.1
[Host] : .NET 9.0.0 (9.0.24.20403), X64 RyuJIT
Job-SUANLL : .NET 9.0.0 (9.0.24.18101), X64 RyuJIT
Server=True Toolchain=.NET Core 9.0 RunStrategy=Throughput
BEFORE:
AFTER UPDATED: 2024/04/13 corresponding to commit With custom utf8 and hex encoding combined:
Fixes #46484