Use ReadOnlySpan<char> equivalents for string methods?
See original GitHub issueIs there an existing issue for this?
- I have searched the existing issues
Is your feature request related to a problem? Please describe the problem.
In #39743 I found that there were performance gains available from using someString.AsSpan().IndexOfAny(...)
in the code instead of someString.IndexOfAny(...)
.
This raises the possibility that there are other usages of string
-based operations that could potentially receive a performance boost from using equivalent operations available for spans in the MemoryExtensions
class (though the original motivation was to remove the static char arrays).
To pick a specific example, IndexOf(ReadOnlySpan<char> value, StringComparison comparisonType)
could be used here if AsSpan()
were added:
Assuming a positive improvement of a large enough magnitude (open question: how big would that be?) is available from benchmarking candidate cases (which also raises the possibility of a runtime analyzer to find such candidates in the first place?), would a larger scale adoption of this pattern (and the subsequent sprinkling of AsSpan()
through the code base) be welcomed in ASP.NET Core?
If so, I’d be happy to help out with evaluating/adopting them as determined by such an exercise.
This seems to be the sort of thing where lots of small changes could add up to nice overall benefit, but comes with the potential code style issue of doing so, and the maintenance overhead of continuing to use such a pattern in the code over time.
Describe the solution you’d like
- Benchmark candidate call sites of
string
method usage that haveReadOnlySpan<T>
equivalents available for each project file’s target frameworks. - Update worthy candidate call sites (determined by meeting a TBD threshold of improvement) to add
AsSpan()
(By area? Splitting it up would prevent a giant PR summoning lots of Code Owners for review, for example). - Observe net result on ASP.NET Core benchmarks once all agreed candidates updated.
Additional context
No response
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (5 by maintainers)
Top GitHub Comments
@wcontayon Happy for you to take a look if you’d like to 😃
Triage: this might be worth pursuing on per-request codepaths, and only if the change is simple/low-impact.
The
BindingAddress
example above is an example of a codepath that is only executed a few times (not per-request) so we wouldn’t want to make this change there.