Conversation
Author
|
@dotnet-policy-service agree |
Garume
marked this pull request as ready for review
September 22, 2026 16:43
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Related to #699.
Maintainer feedback requested: I could not find recorded maintainer approval on the issue. Please confirm whether the short-input gains and the documented empty/long-input tradeoffs are acceptable before this is considered ready to merge.
For #699, use a bounded 64-character stack buffer when
Encoding.GetMaxCharCountfits, avoiding the array-pool rent/return pair for short encoded inputs. Larger inputs retain the existing pooled path. The pointer overload ofEncoding.GetChars, its capacity argument, and the actual decoded length remain unchanged. A fixed nonempty buffer also preserves a non-null destination for custom encodings reporting zero characters.This is a performance tradeoff, not a universal throughput improvement or a warmed-allocation reduction. Both versions allocate 0 B for warmed cache hits. On Windows x64/.NET 10.0.1, selected short-input cases improved, while empty input and some pooled cases regressed. The table below includes every measured scenario. ARM64, other runtimes, cache misses, and contention have not been benchmarked.
Validation:
Benchmarks compare compiled baseline and candidate libraries; the baseline assembly was renamed to allow aliases in the same harness. These are single-machine screening measurements, with one benchmark process per case, three warmups, and eight measured iterations. Maintainer feedback on the short-input/empty-input tradeoff is welcome.
Developed with AI assistance; changes and validation were reviewed before submission.
PR Checklist
b135626dd54d33b8f05f2ff31591592c004aa848).Benchmark harness and reproduction layout
Build the full-history baseline checkout with
-p:AssemblyName=CommunityToolkit.HighPerformance.Baseline, then build this PR's checkout normally. The projects below use aliases to compare both compiled libraries. The measurements above used baselineb135626dd54d33b8f05f2ff31591592c004aa848and candidate879500f891a2dbd8b526938dc7d434394ec6bd3a.Directory layout:
From the common parent directory, first restore and build the baseline checkout:
Place the following files in
toolkit-first-evidence/benchmark. The pinned prerelease BenchmarkDotNet package is available from the publichttps://pkgs.dev.azure.com/dnceng/public/_packaging/benchmark-dotnet-prerelease/nuget/v3/index.jsonfeed; include nuget.org for its dependencies. Rundotnet run -c Release -- --filter '*' --artifacts resultsfrom that directory. Use an isolated NuGet.Config if unrelated machine-wide package sources interfere.Benchmark.csproj:Program.cs: