Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Improve DateTime{Offset} formatting further in a variety of cases #84963

Merged
merged 4 commits into from
Apr 19, 2023
Merged

Improve DateTime{Offset} formatting further in a variety of cases #84963

merged 4 commits into from
Apr 19, 2023
+812 −550

Commits on Apr 19, 2023

  1. Improve DateTime{Offset} formatting further in a variety of cases 

    - Utf8Formatter special-cases 'G' / the default format. By moving that specialized implementation into DateTimeFormat, we can benefit from it from DateTime{Offset}.ToString/TryFormat as well.  This was the last custom formatting routine in Utf8Formatter.  As part of deleting two Utf8Formatter.Date.* files, I also changed the TryFormatDateTimeL shim function to go directly to TryFormatR rather than going through the wrapping TryFormat function.

- The "s" and "u" formats are also reasonably popular and have a fixed pattern that's not sensitive to culture.  By writing custom routines for those, we can not only speed them up, but also restructure the calling code to avoid needing the FormatIntoBuilder for some default/G cases.

- The above requires being able to check whether a provider is invariant, but DateTimeFormatInfo.InvariantInfo and CultureInfo.InvariantCulture.DateTimeFormat actually returned different instances.  I made them the same instance, such that we can now just compare against DateTimeFormatInfo.InvariantInfo to handle the 99.9% case of checking whether a DTFI represents the invariant culture.  This also make access to DTFI.InvariantInfo faster, as it's now just returning a static readonly field rather than a lazily-initialized volatile field.

- For "U", we were allocating a new DateTimeFormatInfo and GregorianCalendar (and supporting strings) on every formatting, resulting in ~1K of allocation.  I fixed it to only allocate when necessary, which is rare.

- Removed some bounds checking in ParseRepeatPattern and various DateTimeFormatInfo.GetXx helpers

- Removed a % from 'h' handling in FormatCustomized.

- Plus a few renames and changing DateTimeOffsetPattern to not access a lazily-initialized property on every iteration of the search loop.

- And Tarek noticed one place we were appending an unchecked char that could have been non-ASCII, so I fixed that to check appropriately.
    @stephentoub
    stephentoub committed Apr 19, 2023
    Configuration menu
    Copy the full SHA
    f05631a View commit details
    Browse the repository at this point in the history

  2. Address PR feedback

    @stephentoub
    stephentoub committed Apr 19, 2023
    Configuration menu
    Copy the full SHA
    03caa36 View commit details
    Browse the repository at this point in the history

  3. Merge branch 'main' into formatsg

    @stephentoub
    stephentoub committed Apr 19, 2023
    Configuration menu
    Copy the full SHA
    ac826ed View commit details
    Browse the repository at this point in the history

  4. Fix TryFormat optimization

    @stephentoub
    stephentoub committed Apr 19, 2023
    Configuration menu
    Copy the full SHA
    69449d2 View commit details
    Browse the repository at this point in the history