Conversation
|
Tagging subscribers to this area: @dotnet/area-system-runtime Issue Details
ReplaceLineEndings LF => LF
ReplaceLineEndings CRLF => LF
ReplaceLineEndings CRLF => CRLF
SpanLineEnumerator
|
|
Comparing the combined change of #81630 + #80963 + #78678 against main without them (NET 7 vs 8): ReplaceLineEndings LF => LF
ReplaceLineEndings CRLF => LF
ReplaceLineEndings CRLF => CRLF
SpanLineEnumerator
|
|
Any thoughts on this @dotnet/area-system-runtime? |
src/libraries/System.Private.CoreLib/src/System/String.Manipulation.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/System/String.Manipulation.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Out of curiosity, I wonder what the performance profile would look like for instead doing the equivalent of a Count("\r\n"), then allocating a string of exactly the right length (string.Length - count), and then formatting directly into that string, rather than going into a growable VSB and then copying into a new string at the end.
There was a problem hiding this comment.
Given this is effectively a glorified string.Replace, we could use a similar approach of building the list of indices.
I'll try it out.
There was a problem hiding this comment.
Tested with MihaZupan@b68c952 and it's similar or a bit worse across the board.
56953a0 to
c21efe3
Compare
IndexOfNewlineCharuntil something other than thereplacementTextis found'\n'- default on non-Windows), we can avoid searching for the line feed, thus avoiding breaking out of the vectorized path unnecessarilySpanHelpers.IndexOfAnyValueTypeReplaceLineEndings LF => LF
ReplaceLineEndings CRLF => LF
ReplaceLineEndings CRLF => CRLF
SpanLineEnumerator