Improve DateTime.ParseExact perf for invariant culture #82877
Conversation
stephentoub
added
area-System.Globalization
tenet-performance
|
Tagging subscribers to this area: @dotnet/area-system-globalization Issue DetailsSpeed up the handling of ddd, dddd, MMM, and MMMM parts of a date time format string when using the invariant culture, which is very commonly used in parsing. Today, when one of these is encountered, the relevant array of comparison strings is retrieved from the DateTimeFormatInfo, and each is compared as a prefix against the current position in the input, using a linguistic ignore-case comparison. But for the invariant culture, we don't need to consult any arrays, and can do the comparison much more quickly. These parts dominate the processing of a format like that for RFC1123.
const string Format = "ddd, dd MMM yyyy HH':'mm':'ss 'GMT'";
private string _s = new DateTime(1955, 11, 5, 6, 0, 0, DateTimeKind.Utc).ToString(Format, CultureInfo.InvariantCulture);
[Benchmark]
public void ParseExact() => DateTimeOffset.ParseExact(_s, Format, CultureInfo.InvariantCulture, DateTimeStyles.AllowInnerWhite | DateTimeStyles.AssumeUniversal);
|
Speed up the handling of ddd, dddd, MMM, and MMMM parts of a date time format string when using the invariant culture, which is very commonly used in parsing. Today, when one of these is encountered, the relevant array of comparison strings is retrieved from the DateTimeFormatInfo, and each is compared as a prefix against the current position in the input, using a linguistic ignore-case comparison. But for the invariant culture, we don't need to consult any arrays, and can do the comparison much more quickly. These parts dominate the processing of a format like that for RFC1123.
src/libraries/System.Private.CoreLib/src/System/Globalization/DateTimeParse.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/System/Globalization/DateTimeParse.cs
Show resolved
Hide resolved
| } | ||
| else | ||
| { | ||
| // Scan the month names (note that some calendars has 13 months) and find |
There was a problem hiding this comment.
| // Scan the month names (note that some calendars has 13 months) and find | |
| // Scan the month names (note that some calendars have 13 months) and find |
There was a problem hiding this comment.
Thanks. These are both pre-existing. If I have to restart CI for some reason, I'll take the comment fixes.
| { | ||
| // Scan the month names (note that some calendars has 13 months) and find | ||
| // the matching month name which has the max string length. | ||
| // We need to do this because some cultures (e.g. "cs-CZ") which have |
There was a problem hiding this comment.
| // We need to do this because some cultures (e.g. "cs-CZ") which have | |
| // We need to do this because some cultures (e.g. "cs-CZ") have |
|
Failures are known |
ghost
locked as resolved and limited conversation to collaborators
Speed up the handling of ddd, dddd, MMM, and MMMM parts of a date time format string when using the invariant culture, which is very commonly used in parsing. Today, when one of these is encountered, the relevant array of comparison strings is retrieved from the DateTimeFormatInfo, and each is compared as a prefix against the current position in the input, using a linguistic ignore-case comparison. But for the invariant culture, we don't need to consult any arrays, and can do the comparison much more quickly. These parts dominate the processing of a format like that for RFC1123.